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ABSTRACT 


Computer  and  network  security  is  a  complex  problem  and  one  that  is  not  solely 
restricted  to  classified  computer  systems  and  networks.  Accelerating  trends  in  networking 
and  the  emphasis  on  open  and  interoperable  networks  has  left  many  unclassified  systems 
vulnerable  to  a  wide  variety  of  attacks.  Computer  and  network  professionals  must 
understand  the  scope  of  security,  recognize  the  need  for  security  for  even  imclassified 
systems  and  then  take  steps  to  protect  their  systems. 

Transmission  of  static  passwords  in  plaintext  over  the  Internet  is  one  of  the  most 
widely  publicized  network  vulnerabilities.  One-time  password  mechanisms  (such  as  S-Key) 
or  other  secure  network  access  mechanisms  (such  as  Kerberos)  have  been  recommended  to 
improve  access  security  for  computer  systems  connected  to  the  Internet. 

This  thesis  .examines  many  of  the  issues  that  must  be  addressed  when  assessing  the 
need  for  computer  and  network  security.  This  work  provides  the  results  of  a  site  security 
survey  for  the  unclassified  IP/ ATM  LAN  in  the  Systems  Technology  Lab  at  the  Naval 
Postgraduate  School.  These  results  highlight  new  security  vulnerabilities  and  strengths  that 
occur  when  standard  Internet  Protocol  (IP)  local-area  networks  (LANs)  are  internetworked 
with  Asynchronous  Transfer  Mode  (ATM)  wide-area  networks  (WANs).  Finally,  we 
examine  the  feasibility  of  the  Kerberos  authentication  protocol  for  remote  plaintext  password 
protection  and  provide  recommendations  for  additional  work. 
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I.  INTRODUCTION 


A.  PROBLEM  DEFINITION 

Computer  and  network  security  is  a  complex  problem  and  one  that  is  no  longer 
unique  to  classified  networks.  The  Internet  and  internetworked  computer  systems  in 
general  offer  incredible  financial,  educational,  scientific  and  recreational  opportunities. 
While  the  ease  with  which  individuals  and  organizations  are  able  to  transmit  and  retrieves 
data  and  information  around  the  world  is  certainly  attractive,  it  does  not  come  without 
pitfalls.  Threats  to  computer  system  security  and  network  security  abound.  The  problem 
faced  by  many  organizations,  including  the  Department  of  Defense  (DoD),  is  being  able 
to  take  advantage  of  this  global  internetworking  trend  without  compromising  proprietary 
or  sensitive  information,  or  falling  prey  to  malicious  attacks  against  the  normal  operation 
of  their  networked  computer  systems. 

Personal  data,  credit  card  numbers,  proprietary  business  information  and  sensitive 
research  data  must  be  protected  both  while  stored  in  host  systems  and  while  being 
transmitted  over  the  network.  Many  people  believe  that  new  networking  technologies 
such  as  Asynchronous  Transfer  Mode  (ATM)  will  significantly  reduce  the  threats  to 
networked  computer  system  security.  However,  current  networking  technology  will 
remain  in  place  for  the  foreseeable  future.  Regardless  of  whether  the  physical  technology 
and  protocols  used  for  the  Internet  backbone  are  based  on  routed  IP  packets  or  switched 
ATM  circuits,  internetworking  trends  will  continue.  We  are  beginning  to  see 
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internetworked  hybrids  of  both  approaches,  along  with  a  need  for  a  keener  focus  on 
computer  and  network  security. 

Computer  and  network  security  is  primarily  a  management  issue,  one  that 
historically  has  been  a  low  priority.  Managers  must  understand  internetworking  trends 
and  the  threats  to  networked  computer  system  security.  They  must  recognize  the  need  to 
secure  even  unclassified  networks.  This  thesis  focuses  on  the  security  threats  and 
vulnerabilities  associated  with  internetworking  a  Internet  Protocol  (IP)  local-area  network 
(LAN)  and  an  Asynchronous  Transfer  Mode  (ATM)  wide-area  network  (WAN)  at  the 
Naval  Postgraduate  School  (NPS). 

B.  MOTIVATION 

1.  Growth  of  the  Internet 

The  incredible  growth  of  the  Internet  and  the  technological  advances  in  modem 
computer  network  communications  has  made  global  communication  and  information 
interchange  a  reality.  Individual  and  organizational  computer  systems  are  accessible  to 
millions  of  other  computers  and  individuals  where  they  were  once  relatively  sheltered. 

Over  the  past  25  years  the  Internet  has  experienced  incredible  growth.  Table  1'  shows 
that  in  the  last  year  alone,  the  number  of  computer  hosts  connected  to  the  Internet  has 
nearly  doubled  and  the  number  of  networks,  as  indicated  by  the  Network  Class  figures, 
has  more  than  doubled  (Lottor,  1996).  These  statistics  should  be  considered  minimums 
due  to  incomplete  data  collection  as  discussed  in  (Lottor,  1992). 

'  Data  in  Tables  1  and  2  were  produced  by  Network  Wizards  and  is  used  by  permission. 

The  original  survey  data  are  available  at  http://www.nw.com/ 
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Date 

Hosts 

Domains 

Network  Class 

A 

B 

C 

Jan  96 

9,472,000 

240,000 

92 

5655 

87,924 

Jul95 

6,642,000 

120,000 

91 

5390 

56,057 

Jan  95 

4,852,000 

71,000 

91 

4979 

34,340 

Table  1.  Number  of  hosts,  domains  and  networks  advertised  in  the  Domain 
Name  System  (DNS).  After  (Lottor,  1996). 


While  the  Internet  was  initially  implemented  in  the  1970's  as  a  demonstration 
project  using  new  networking  technology  for  the  U.S.  Government  (Rowe,  1995;  Krol, 
1994;  Claffy,  et  al.,  1994),  Table  2  shows  that  the  Internet  now  connects  millions  of 
computers  on  tens  of  thousands  of  networks  belonging  to  governments,  organizations, 
businesses  and  academia  from  around  the  world  (Lottor,  1996).  This  growth  will 
imdoubtedly  continue. 


Domain 

Hosts 

Commercial  (com) 

2,430,954 

Educational  (edu) 

1,793,491 

Networks  (net) 

758,597 

Germany  (de) 

452,997 

United  Kingdom  (uk) 

451,750 

Canada  (ca) 

372,891 

Government  (gov) 

312,330 

Australia  (au) 

309,562 

Organizations  (org) 

265,327 

U.S.  Military  (mil) 

258,791 

Total: 

7,406,690 

Table  2.  Host  distribution  by  top-level  domain 


name  (Lottor,  1996). 


3 


DoD  use  of  the  Internet  also  continues  to  increase.  The  U.S.  DoD  (i.e.  the  mil 
domain)  ranks  tenth  with  regard  to  the  number  of  hosts  connected  to  the  Internet,  and  the 
Pentagon  continues  working  to  take  advantage  of  internetworking  capabilities  and 
emerging  technologies.  All  of  the  military  services  emphasize  the  need  for  integrating 
computer  and  communication  networks  and  for  using  cutting  edge  technology  (Sullivan, 
1995;  CNO,  1995;  Fogleman  and  Widnall,  1995).  These  integrated  networks  (or  at  least 
the  information  they  transport)  will  need  to  be  secure  to  be  effectively  used  by  the  mili¬ 
tary  commander  in  the  field  (Nierle,  1996). 

2.  The  Need  for  Computer  Security 

The  need  for  computer  and  network  security  is  obvious  when  speaking  about 
classified  defense  information  or  when  viewed  from  a  national  defense  perspective. 
However,  although  NPS  is  a  military  installation,  its  mission  is  not  to  provide  national 
defense  but  to  enhance  it  by  providing  graduate  and  professional  education  for  U.S.  and 
allied  military  officers  (NPS,  1995).  If  NPS  only  has  an  indirect  effect  on  national 
security,  why  should  it  (or  any  other  educational  institution)  be  concerned  with  computer 
system  and  network  security?  Why  should  business  and  industry  (aside  from  those 
defense  contractors  developing  classified  technology)  be  concerned  with  networked 
computer  system  security?  These  questions  deserve  analysis. 

The  original  "Internet,"  which  consisted  initially  of  the  DoD's  Advanced  Research 
Project  Agency  Network  (ARPANet)  and  later  the  National  Science  Foundation  Network 
of  supercomputers  (NSFNET),  was  developed  primarily  to  allow  collaborating  research¬ 
ers  to  exchange  files  and  electronic  mail  messages  among  one  another.  To  this  day,  the 
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Internet  is  essential  for  collaborative  research  among  academia,  industry  and  the  military, 
but  the  Internet  user  community  is  no  longer  composed  strictly  of  benevolent  academi¬ 
cians  and  researchers  exchanging  data  and  communications  for  the  good  of  science. 
Banking  services,  electronic  commerce,  international  business  transactions  and  a  host  of 
commercial  on-line  services  all  compete  for  network  bandwidth.  (Krol,  1994;  Boucher, 
1994)  Not  all  Internet  users  are  model  citizens;  some  seek  to  exploit  system  and  network 
weaknesses  either  out  of  malice  or  else  for  personal  or  professional  gain. 

These  malicious  users  are  not  necessarily  external  to  one's  own  organization. 
Statistics  show  that  external  attacks  account  for  less  than  3%  of  reported  losses  while 
malicious  insiders  account  for  approximately  19%  and  mistakes  made  by  well-intentioned 
insiders  account  for  approximately  65%  of  reported  losses  (Wong  and  Watt,  1990). 
Therefore  the  networked  computer  system  security  umbrella  must  protect  an  organization 
against  threats  from  inside  as  well  as  outside  the  organization.  The  important  point  is  that 
even  if  only  0.01%  of  the  estimated  20  million  Internet  users  (Blum,  1995-1996; 

Boucher,  1994)  is  attempting  to  gain  unauthorized  access  or  otherwise  cause  damage  to 
your  computer  systems/networks  or  the  data  they  contain,  whether  they  are  inside  or 
outside  your  organization,  there  are  still  20,000  wolves  at  the  door.  The  most  frightening 
aspect  of  these  wolves  is  that  they  can  be  at  more  than  one  networked  door  at  a  time,  they 
can  use  a  variety  of  techniques  to  gain  access  to  computer  systems,  and  their  actions  can 
have  long-lasting  effects. 

If  the  mere  possibility  of  a  computer  security  incident  doesn't  convince  computer 
system  users,  administrators  and  managers  of  the  need  for  computer  security,  the 
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applicable  laws  and  regulations  should.  Table  3  lists  a  number  of  laws  and  directives  that 
are  relevant  to  this  thesis.  These  laws  and  directive  proscribe  various  security  require¬ 
ments  for  federal  computer  systems.  The  following  bullets  briefly  describe  each  of  these 
laws  and  directives. 

•  The  Privacy  Act  of  1974  was  enacted  largely  in  response  to  growing 
public  concern  over  the  privacy  of  personal  information  gathering  in 
various  government  databases  in  the  early  1970's  (Russell  and  Gangemi, 
1991). 

•  Office  of  Management  and  Budget  (0MB)  Circular  A-71  requires  federal 
agencies  under  the  jurisdiction  of  the  executive  branch  to  establish  and 
maintain  computer  security  programs  (Russell  and  Gangemi,  1991;  DoN, 
1991). 

•  0MB  Circular  A-1 30  (Management  of  Federal  Information  Resources, 
1985)  extended  the  A-71  requirement  to  all  federal  agencies. 

•  The  Computer  Fraud  and  Abuse  Act  of  1986  (Public  Law  99-474;  amend¬ 
ment  to  title  18  U.S.  Code,  section  1030)  was  enacted  to  combat  the 
growing  number  of  computer  crimes  in  the  early  1980's  —  crimes  that  cost 
federally  insured  financial  institutions  an  estimated  $730  million  in  1985. 
This  act  also  prohibits  unauthorized  access  to  computer  systems  owned  or 
operated  by  or  on  behalf  of  the  Federal  Government.  (Toensing,  1986). 

•  The  Computer  Security  Act  of  1987  (Public  Law  100-235)  requires  all 
U.S.  government  computer  systems  containing  sensitive  information  to 
have  a  customized  security  plan  (Russell  and  Gangemi,  1991;  DoN,  1991). 


•  The  Privacy  Act  of  1974 

•  0MB  Circular  A-1 1 

•  0MB  Circular  A- 1 3  0 

•  The  Computer  Fraud  and  Abuse  Act  of 
1986 

•  The  Computer  Security  Act  of  1987 

•  DoD  Directive  5200.28 

•  SECNAVINST  5239.2 


Table  3.  Relevant  laws  and  directives  governing 
computer  security. 
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•  Department  of  Defense  (DoD)  Directive  5200.28  "Security  Requirements 
for  Automated  Information  Systems  (AISs)"  outlines  the  security  require¬ 
ments  for  all  automated  information  systems  operated  by  or  for  the  DoD 
(SPA  WAR,  1993;  DoN,  1991). 

•  Secretary  of  the  Navy  Instruction  (SECNAVINST)  5239.2  "Department  of 
the  Navy  Automated  Information  Systems"  provides  specific  guidelines 
that  apply  to  automated  information  systems  operated  by  or  for  the  Depart¬ 
ment  of  the  Navy  (SPAWAR,  1993;  DoN,  1991). 

C.  THESIS  OBJECTIVES 

There  are  two  primary  objectives  for  this  thesis.  The  first  objective  is  to  docu¬ 
ment  the  results  of  a  site  security  survey  for  the  unclassified  IP/ATM  LAN/WAN  at  NPS 
and  identify  areas  that  are  deficient.  The  second  objective  is  to  provide  a  secure  remote 
login  capability  to  the  IP/ATM  LAN/WAN  at  NPS  for  mobile  users  and  for  research 
partners  at  Old  Dominion  University  in  Norfolk  Virginia. 

D.  THESIS  STRUCTURE 

1.  Scope 

An  overwhelming  variety  of  subjects  might  be  examined  when  studying  net¬ 
worked  computer  security.  We  have  focused  on  practical  and  experimentally  verifiable 
issues  of  immediate  interest.  The  scope  of  this  thesis  is  limited  to  a  discussion  of  the 
security  issues  relevant  to  the  integrated  IP/ATM  LAN/WAN  at  NPS,  documenting  the 
results  of  a  site  security  survey  for  the  IP/ATM  LANAVAN  at  NPS,  and  implementing 
and  testing  the  Kerberos  authentication  and  authorization  protocol  to  improve  remote  user 
access  security  of  the  IP/ ATM  LAN/WAN  at  NPS. 
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2.  Organization 

This  introductory  chapter  defines  the  general  problem  and  explains  the  motivation 
for  the  research  described  and  documented  in  this  thesis.  Chapter  II  presents  background 
information  necessary  to  understand  the  remainder  of  this  work  and  describes  some 
related  internetworking  and  networked  computer  system  security  research.  Chapter  III 
presents  a  detailed  problem  statement.  Chapter  IV  discusses  many  of  the  issues  that 
managers  must  address  when  determining  the  type  and  extent  of  controls  required  to 
adequately  secure  their  networked  computer  system.  Chapter  V  describes  the  Kerberos 
authentication  and  authorization  protocol.  Chapter  VI  documents  the  results  of  a  site 
security  survey  for  the  IP/ ATM  LAN/WAN  at  NPS.  Chapter  VII  describes  the  steps 
taken  to  implement  the  Kerberos  software  in  the  NPS  Systems  Technology  Lab  (STL). 
Research  conclusions  and  recommendations  for  further  work  are  presented  in  Chapter 
VIII. 
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11.  BACKGROUND  AND  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  provides  background  information  and  briefly  discusses  related  inter¬ 
networking  and  computer  security  research.  Section  B  defines  the  concepts  and  purpose 
of  computer  security  for  our  context.  Section  C  discusses  the  International  Standards 
Organization  (ISO)  Open  Systems  Interconnection  (OSI)  logical  reference  model  for 
network  communications  and  how  computer  security  can  be  implemented  within  the 
framework  of  the  OSI  model.  The  Internet  protocol  model  is  briefly  discussed  and 
contrasted  with  the  OSI  model  in  Section  D.  A  general  discussion  of  ATM,  its  relation¬ 
ship  to  the  Internet  model  and  its  vulnerabilities  with  regard  to  security  is  provided  in 
Section  E.  The  chapter  concludes  with  a  discussion  of  related  internetworking  and 
security  research  in  Section  F. 

B.  COMPUTER  SECURITY  BACKGROUND 

Computer  security  is  a  broad  subject.  Before  we  can  discuss  the  subject  we  must 
first  define  precisely  what  it  is  we  are  discussing.  Subsection  1  defines  computer  security 
and  explains  its  purpose.  Subsection  2  describes  the  Department  of  the  Navy’s  computer 
security  program  (DoN,  1991).  Subsection  3  clarifies  the  terms  threat,  vulnerability,  risk 
and  control  as  used  in  the  context  of  networked  computer  security. 
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1. 


Definition  and  Purpose 


Ask  ten  different  computer  professionals  for  the  definition  and  purpose  of 

computer  security  and  you  are  likely  to  receive  ten  different  variations  on  a  theme.  The 

following  quotations  serve  to  illustrate  this  point. 

'  [Computer  security  is]  the  protection  of  the  computer  resources  against 
accidental  or  intentional  disclosure  of  confidential  data,  unlawful  mod¬ 
ification  of  data  or  programs,  the  destruction  of  data,  software  or  hard¬ 
ware,  and  the  denial  of  one's  own  computer  facilities  . . .."  (Palmer  and 
Potter,  1989,  pg.  12) 

"[Computer  security  is]  the  protection  of . . .  systems  and  their  data, 
against  any  accidental  or  deliberate  compromise  of  proprietary  data  and 
programs  . . .  and  assuring  their  continuous  availability  to  users  . . . 
through  built-in  system  resilience  features  to  minimise  short  term  disrup¬ 
tions,  and  contingency  planning,  to  mitigate  protracted  system  stoppage 
from  natural  or  man-made  disasters."  (Wong  and  Watt,  1990,  pg.  23) 

Computer  security  is  the  protection  of  your  "computer  and  everything 
associated  with  it . . .."  (Russell  and  Gangemi,  1991) 

Even  the  military  services  do  not  agree  precisely  on  what  computer  security  is.  The  U.S. 

Air  Force  defines  computer  security  as  the  protection  of  information  confidentiality, 

integrity  and  availability  (Fleming,  1993),  while  the  U.S.  Navy  defines  automated 

information  system  (AIS)  security  as  the  policies  and  procedures  taken  to  “protect  AISs 

against  unauthorized  (accidental  or  intentional)  destruction,  modification,  disclosure  and 

denial  of  service”  (DoN,  1991,  para.  1.1). 

Despite  subtle  variations  in  the  definitions  given  above,  each  is  an  appropriate 
definition  of  computer  security.  Nevertheless  some  concepts  are  more  appropriate  than 
others  for  today's  internetworked  computing  environment.  Where  once  computer  security 
focused  on  securing  access  to  a  central  mainframe  computer,  security  in  today's 
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distributed  computing  environment  requires  a  much  broader  scope.  One  cannot  consider 
the  security  of  an  individual  computer  without  considering  the  security  of  the  information 
that  is  processed  by  that  computer  regardless  of  whether  the  information  is  stored  on  the 
computer  itself  or  on  a  secondary  storage  device.  Likewise  in  the  case  of  networked 
computers,  one  cannot  consider  computer  and  information  security  without  considering 
the  security  of  the  network  over  which  the  information  is  transmitted.  (Cobb,  1992; 
Baskerville,  1988;  Reeves,  1983) 

This  thesis  focuses  on  a  local-area  network  (LAN)  owned  and  operated  by  the 
Naval  Postgraduate  School  (NPS)  and  therefore  uses  the  computer  security  definition 
outlined  in  the  Department  of  the  Navy  (DoN)  Automated  Information  Systems  (AIS) 
Security  Guidelines  (DoN,  1991).  The  definition  applies  to  the  hardware,  the  software 
and  the  data,  regardless  of  whether  such  data  is  in  storage,  is  being  processed  by  the 
central  processing  unit  or  is  being  transmitted  over  a  network.  Thus  the  terms  automated 
information  system  (AIS)  security,  system/network  security  and  internetworked  computer 
security  are  used  interchangeably  throughout  the  remainder  of  this  thesis. 

2.  DoN  AIS  Security  Guidelines 

The  Department  of  the  Navy  divides  its  overall  security  program  into  seven  inter¬ 
dependent  elements.  These  elements  are  shown  in  Table  4.  Although  each  element  is 
described  and  governed  by  a  separate  instruction,  all  categories  overlap  to  a  great  extent. 
For  example,  the  DoN  AIS  Security  Guidelines  (the  first  element  in  Table  4)  document 
the  roles,  responsibilities  and  requirements  for  ensuring  adequate  information  security, 
network  and  data  communications  security,  personnel  security,  physical  security  and 
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•  AIS  Security 

•  Information  Security 

•  Communications  Security 
o  Cryptographic  seciuity 
o  Physical  security 

o  Transmission  security 
o  Emission  security 

•  Personnel  Security 

•  Physical  Security 

•  Emanations  Security  (TEMPEST) 

•  Network  Security 

o  Network  integrity 
o  Data  authentication 
o  Field  integrity 
o  Non-repudiation 
o  Protocol-based  protection 
o  Connection  confidentiality 
o  Access  control 

Table  4.  DoN  security  program  elements 
(DoN,  1991,  para.  1.5). 


emanations  security  as  each  applies  to  automated  information  systems  (AISs).  Although 
it  may  seem  that  some  of  these  elements  are  meaningless  outside  the  context  of  AISs, 
each  individual  element  does  in  fact  encompass  a  much  broader  scope. 

The  primary  purpose  of  the  DoN  AIS  Security  Guidelines  is  to  assist  Navy 
commands  and  "activities  in  meeting  the  intent  of  the  DoN  AIS  Security  policies" 
(emphasis  added)  (DoN,  1991,  para.  1.4).  Some  readers  may  argue  that  the  list  in  Table  4 
is  incomplete  in  that  it  does  not  include  system  availability.  This  is  indeed  an  important 
factor  of  computer  security  as  discussed  in  Chapter  IV.  However,  although  the  list  does 
not  explicitly  include  it,  system  availability  is  implicitly  considered  in  the  risk  analysis 
methodology  outlined  in  the  guidelines. 
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The  DoN  AIS  Security  Guidelines  are  not  merely  an  implementation  checklist. 
They  are  a  management  tool  commanding  officers  or  other  responsible  individuals  can 
use  to  determine  the  required  level  of  security  for  the  activity’s  AISs.  The  guidelines 
provide  a  methodology  and  sample  documentation  that  commands  and  activities  can  use, 
both  to  analyze  the  security  of  their  AISs  and  to  determine  if  adequate  threat  controls  are 
in  place  to  operate  those  AISs  at  an  acceptable  level  of  risk.  What  constitutes  the 
appropriate  amount  of  security  and  the  acceptable  level  of  risk  are  management  decisions 
that  will  vary  from  system  to  system. 

3.  Threats,  Vulnerabilities,  Risks  and  Controls 

Whichever  definition  is  chosen,  AIS  security  is  the  art  of  mitigating  threats  by 
eliminating  or  reducing  system  vulnerabilities  through  the  application  of  controls  in  order 
to  minimize  threat  impact  and  the  risk  of  loss.  Unfortunately  these  three  terms  —  threat, 
vulnerability  and  risk  —  are  used  often  indiscriminately.  For  example,  the  DoN  AIS 
Security  Guidelines  treat  the  terms  "threat"  and  "vulnerability"  synonymously.  However, 
the  three  terms  are  clearly  distinct.  The  following  paragraphs  define  these  terms. 

Threats  are  possible  pitfalls  or  dangers  confronting  an  information  system,  no 
matter  how  likely  or  unlikely  they  may  be.  For  example,  fire  is  a  threat  to  overall 
information  system  security.  In  accordance  with  our  definition  of  AIS  security,  fire  can 
result  in  damaged  or  destroyed  hardware/software/data  or  denial  of  system  services. 
(Fitzgerald,  1993;  Russell  and  Gangemi,  1991)  As  with  fire,  threats  need  not  be  directed 
at  or  against  the  information  system  per  se,  but  may  simply  be  a  product  of  the 
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environment  that  could  cause  coincidental  damage  to  the  system.  A  threat  corresponds  to 
a  system  vulnerability  only  in  the  absence  of  adequate  proactive  controls. 

A  vulnerability  represents  a  security  weakness  in  the  system  that  might  result  in  a 
potential  loss  if  that  weakness  is  exploited  by  a  threat  (Fitzgerald,  1993;  Fleming,  1993; 
Russell  and  Gangemi,  1991;  Wong  and  Watt,  1990;  Palmer  and  Potter,  1989).  The 
frequency  at  which  a  threat  may  occur  is  not  a  factor  when  determining  system  vulnera¬ 
bilities.  For  example,  if  an  information  system  does  not  have  an  operative  or  adequate 
fire  suppression  system  or  other  fire  protection  mechanism,  this  lack  of  fire  protection  is  a 
system  vulnerability  no  matter  how  rarely  a  fire  may  actually  occur.  (Wong  and  Watt, 
1990) 

Risk  is  a  measure  of  the  possible  impact  or  loss  that  may  result  if  a  threat  actually 
exploits  a  system  vulnerability.  The  level  of  risk  will  depend  on  the  controls  in  place,  the 
value  of  the  assets  affected  and  the  likelihood  that  the  threat  will  actually  occur.  (Cobb, 
1992;  Wong  and  Watt,  1990;  Palmer  and  Potter,  1989;  DoN,  1991) 

Controls  are  the  countermeasures,  protection  mechanisms  or  safeguards  imple¬ 
mented  to  counter  threats  to  a  system  and  to  reduce  the  risk  of  loss.  Traditionally  controls 
have  one  of  three  purposes:  prevention,  detection  or  correction.  Preventative  controls  are 
designed  to  prevent  or  hinder  a  threat  from  occurring.  Detective  controls  are  designed  to 
alert  users  and/or  system  administrators  if  a  particular  threat  or  event  occurs.  Corrective 
controls  are  designed  to  assist  users  and/or  system  administrators  in  recovering  after  a 
threat  or  event  occurs.  (Fitzgerald,  1993;  Russell  and  Gangemi,  1991;  Wong  and  Watt, 
1990;  Baskerville,  1988) 
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Now  that  computer  security  has  been  defined,  its  purpose  explained  and  some 
frequently  misunderstood  terms  clarified,  a  brief  discussion  of  network  communication 
protocols  is  in  order.  The  next  three  sections  briefly  discuss  the  ISO  OSI  reference 
model,  the  Internet  protocol  (TCP/IP)  suite  and  emerging  Asynchronous  Transfer  Mode 
(ATM)  technology. 

C.  ISO  OSI  REFERENCE  MODEL 

It  seems  almost  canonical  that  any  discussion  of  networking  must  include  a 
discussion  of  the  International  Standards  Organization  (ISO)  Open  Systems  Interconnec¬ 
tion  (OSI)  logical  reference  model  for  network  and  data  communications.  While  it  is 
important  to  have  a  basic  understanding  of  the  functionality  associated  with  each  layer  in 
the  OSI  model,  one  must  realize  that  the  model  is  only  conceptual.  It  is  not  an  implemen¬ 
tation  guide.  The  OSI  model  merely  provides  a  convenient  way  for  researchers,  techni¬ 
cians  and  computer  professionals  to  discuss  network  functionality.  Subsection  1 
describes  the  functionality  of  each  layer  of  the  OSI  model  and  Subsection  2  describes  the 
security  services  associated  with  each  layer  of  the  model. 

1.  Network  Functionality  in  the  OSI  Model 

The  ISO  OSI  logical  reference  model  is  shown  in  Figure  1.  Each  layer  of  the  OSI 
model  outlines  a  particular  function  with  regard  to  data  and  network  communications. 

The  bottom  three  layers  —  the  physical  layer,  the  data  link  layer  and  the  network 
layer  —  work  together  to  actually  access  the  network  and  get  the  data  onto  the  “wires.” 
The  physical  layer  is  responsible  for  bit  encoding  (i.e.  transforming  binary  code  into  the 
appropriate  form  for  transmission  on  the  physical  medium).  This  layer  is  responsible  for 
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Figure  1.  ISO  OSI  reference  model. 

making  the  physical,  electrical  and/or  mechanical  connection  to  the  physical  medium  and 
is  concerned  with  transmitting  and  receiving  the  data  stream  onto  and  from  the  network. 
The  data  link  layer  is  responsible  for  point-to-point  message  synchronization  and 
integrity  and  is  concerned  with  encapsulating  the  data  into  data  units  and  calculating  error 
checksums.  The  network  layer  is  responsible  for  efficient  routing  across  a  switched 
network  and  is  concerned  with  logical-to-physical  address  resolution.  (Fitzgerald,  1993; 
Russell  and  Gangemi,  1991;  Wong  and  Watt,  1990) 

The  top  four  layers  —  the  transport  layer,  the  session  layer,  the  presentation  layer 
and  the  application  layer  —  work  together  to  establish  a  connection  and  to  format  the  data 
for  presentation  to  the  lower  three  layers.  The  transport  layer  is  responsible  for  end-to- 
end  data  integrity,  message  assembly/disassembly  and  connection  management.  The 
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session  layer  is  responsible  for  establishing  and  maintaining  the  connection  for  a 
particular  commumcation  session.  The  presentation  layer  is  responsible  for  formatting 
data  for  user  applications  and  other  devices  on  the  network.  Finally,  the  application  layer 
is  responsible  for  application  software  (e.g.  ftp,  word  processing  etc.)  and  the  end  user’s 

interface  to  the  network.  (Fitzgerald,  1993;  Russell  and  Gangemi,  1991;  Wong  and  Watt, 
1990) 

2.  Security  in  the  OSI  Model 

There  are  five  basic  security  services  described  by  the  ISO  Security  Architecture 
that  can  be  implemented  in  any  network.  These  services  are  authentication,  access 
control,  data  confidentiality  (i.e.  secrecy),  data  integrity  and  nonrepudiation  (ISO  7498-2- 
1988(E)).  Authentication  is  the  process  of  verifying  the  identity  of  a  user  or  computer 
process  acting  on  behalf  of  a  user.  Access  control  (i.e.  authorization)  is  the  process  of 
enforcing  the  authorized  use  of  or  access  to  programs,  processes  and  data  by  users  or 
computer  processes  acting  on  behalf  of  users.  Integrity  implies  that  there  has  been  no 
accidental  or  intentional  unauthorized  modification  or  destruction  of  data.  Confidentiality 
implies  that  there  has  been  no  accidental  or  intentional  unauthorized  disclosure  of  data. 
Nonrepudiation  is  the  process  of  protecting  against  denial  of  receipt  or  transmission  of 
data  by  the  receiver  or  sender  respectively.  (McNulty,  1994;  Russell  and  Gangemi,  1991 ; 
Kirkpatrick,  1989)  The  goal  of  these  five  security  services  then  is  to  prevent 
unauthorized  disclosure,  destruction  or  modification  of  data,  or  denial  of  system  services 
in  accordance  with  our  definition  of  AIS  security  (DoN,  1991). 
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With  the  exception  of  the  session  layer,  each  notional  layer  in  the  OSI  model  can 


support  one  or  more  of  these  security  services.  Figure  2  illustrates  the  security  services 
that  each  layer  can  support.  The  physical  layer  can  support  data  confidentiality  using  end- 
to-end  encryption  protocols.  The  data  link  layer  can  also  support  data  confidentiality  by 
using  link-by-link  rather  than  end-to-end  enciyption  protocols.  The  network  and 
transport  layers  can  each  support  authentication,  access  control,  data  confidentiality  and 
data  integrity.  The  presentation  layer  can  support  data  confidentiality.  The  OSI  applica¬ 
tion  layer  can  support  all  five  security  services.  (Buddenberg,  1995;  Russell  and 


Application  Layer: 

Authentication,  Access  Control,  Data 
Confidentiality,  Data  Integrity,  Nonrepudiation 

Presentation  Layer: 

Data  Confidentiality 

Session  Layer: 

Transport  Layer: 

Authentication,  Access  Control,  Data 
Confidentiality,  Data  Integrity 

Network  Layer: 

Authentication,  Access  Control,  Data 
Confidentiality,  Data  Integrity 

Data  Link  Layer: 

Data  Confidentiality 

Physical  Layer: 

Data  Confidentiality 

Figure  2.  Security  services  in  the  OSI  Reference  Model.  After 
(Kirkpatrick,  1989). 


Gangemi,  1991;  Kirkpatrick,  1989)  It  is  important  to  note  that  the  OSI  security  architec¬ 


ture  only  discusses  the  services  each  layer  can  support;  it  says  nothing  about  which 
services  each  layer  should  support. 
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D.  INTERNET  PROTOCOLS 


As  mentioned  in  Section  C,  the  OSI  reference  model  is  largely  notional.  Actual 
network  technology  and  protocol  implementations  do  not  map  neatly  to  the  OSI 
conceptual  model,  yet  actual  implementations  still  provide  essentially  the  same  overall 
functionality.  Subsection  1  below  presents  a  brief  discussion  of  the  common  TCP/IP 
protocol  suite  and  how  it  maps  onto  the  OSI  reference  model.  Subsection  2  discusses 
computer  security  in  the  Internet  model. 

1.  Network  Functionality  in  the  TCP/IP  Protocol  Suite 

The  TCP/IP  protocol  suite  is  composed  of  four  conceptual  layers:  the  network 
interface  layer,  the  network  or  Internet  layer,  the  transport  layer  and  the  application  layer. 
Figure  3  illustrates  how  these  layers  map  onto  the  OSI  model.  Although  the  figure  shows 
a  smooth  mapping,  one  must  realize  that  it  is  not  necessarily  a  direct  mapping;  there  is 
some  functional  overlap  between  the  layers  of  the  OSI  model  and  those  of  the  TCP/IP 
suite.  A  significant  further  difference  is  that  protocols  following  the  OSI  reference  model 
are  constrained  to  communicate  only  with  adjacent  layers,  whereas  interlayer  communica¬ 
tions  in  the  TCP/IP  suite  are  allowed  to  bypass  layers  when  necessary  for  efficiency, 
responsiveness  and  throughput  (Stallings,  1994). 

The  network  access  layer  in  the  TCP/IP  suite  combines  most  of  the  functionality 
of  the  OSI  physical  and  data  link  layers.  However,  where  the  OSI  model  includes  link- 
by-link  error  control  at  the  data  link  layer,  the  TCP/IP  protocol  stack  treats  error  control 
as  an  end-to-end  problem  in  the  transport  layer.  The  network  access  layer  is  responsible 
for  accepting  IP  datagrams  from  the  network  layer,  encapsulating  them  in  network 
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TCP/IP  Protocol  Suite  OSI  Reference  Model 


Figure  3.  Comparison  of  the  TCP/IP  protocol  suite  and  the  OSI  model. 

After  (Varma,  1995). 

specific  frames  and  transmitting  them  over  the  network.  The  TCP/IP  network  access 
layer  may  consist  of  a  simple  device  driver  or  it  may  implement  its  own  complex  data 
link  protocol.  (Comer,  1991) 

The  IP  network  layer  (also  known  as  the  Internet  layer)  provides  functionality 
similar  to  that  described  for  the  OSI  network  layer.  However,  the  OSI  model  only 
describes  functionality  associated  with  a  single  network;  it  does  not  address  internet¬ 
working  as  does  the  TCP/IP  implementation.  The  IP  network  layer  accepts  packets  from 
the  transport  layer,  encapsulates  them  as  Internet  Protocol  (IP)  datagrams  and  passes  the 
IP  datagrams  to  the  network  access  layer.  (Comer,  1991) 

As  mentioned  above,  the  TCP/IP  transport  layer  provides  end-to-end  error  control 
and  other  functionality  similar  to  the  OSI  transport  layer.  Protocols  in  this  layer  include 
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the  connection-oriented  Transport  Control  Protocol  (TCP)  (Postel,  1981)  and  the 
connectionless  User  Datagram  Protocol  (UDP)  (Postel,  1980).  The  TCP/IP  transport 
layer  may  also  implement  some  OSI  session  layer  connection  management  functionality 
in  those  instances  where  TCP  is  implemented.  (Comer,  1991) 

Finally,  the  TCP/IP  application  layer  combines  the  functionality  described  for  the 
OSI  session,  presentation  and  application  layers.  In  the  TCP/IP  implementation,  the 
application  layer  is  responsible  for  determining  whether  the  data  is  to  be  transmitted  as  a 
data  stream  or  as  data  messages  (Comer,  1991). 

2.  Security  in  the  TCP/IP  Protocol  Suite 

The  TCP/IP  protocol  suite  is  a  set  of  interoperable  protocols  for  use  in  an  open 
environment.  For  this  and  historical  reasons,  the  current  version  (IPv4)  protocols 
themselves  are  inherently  insecure.  The  current  TCP/IP  protocols  do  not  prevent 
someone  at  an  intermediate  node  between  source  and  destination  nodes  from  capturing 
and  viewing,  modifying,  destroying,  spoofing  or  redirecting  datagrams  as  they  pass  by  on 
the  network. 

Many  tradeoffs  pertain  when  implementing  security  in  practice.  The  primary 
focus  for  security  in  the  TCP/IP  model  is  at  the  application  layer  (Baker  et  al,  1996). 
Implementing  security  in  higher  layers  typically  requires  a  smaller  Trusted  Computing 
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Base  (TCB)^  to  enforce  a  particular  security  policy.  Generally  a  smaller  TCB  facilitates 
scalability  and  reduces  security  related  costs. 

Despite  the  inherent  insecurity  of  the  current  Internet  protocols,  they  do  support 
some  security  functions.  For  example,  the  transport  layer  incorporates  an  integrity  check¬ 
sum  in  the  transport  control  protocol  (TCP)  packets  and  data  confidentiality  can  be 
supported  at  either  the  network  or  application  layer  using  cryptography  (Comer,  1991). 
Access  control  can  also  be  supported  at  the  application  or  network  layer  with  address 
filtering  or  access  control  lists. 

Security  requirements  have  changed  as  the  Internet  has  migrated  from  primarily  a 
research  and  development  tool  to  encompass  a  much  broader  user  base.  The  IP  Security 
Protocol  (IPSEC)  working  group  within  the  Internet  Engineering  Task  Force  (IETF)  has 
developed  cryptographic  security  protocol  specifications  to  support  combinations  of 
access  control,  authentication,  confidentiality  and  integrity  at  the  network  layer  (Hughes, 
1996;  Atkinson,  1995).^  These  specifications  have  been  incorporated  into  the  next- 
generation  Internet  protocol  (IPv6)  (Bradner  and  Mankin,  1996;  Huitema,  1996;  Nierle, 
1996).  While  the  specifications  are  compatible  with  current  IPv4  protocols,  they  are  not 
widely  used  (Huitema,  1996). 


^  The  Trusted  Computing  Base  (TCB)  is  the  “totality  of  protection  mechanisms  within  a 
computer  system  —  including  hardware,  firmware,  and  software  —  the  combination  of  which  is 
responsible  for  enforcing  a  security  policy”  (DoD,  1985). 

^  Refer  to  Section  F  later  in  this  chapter  for  a  discussion  of  the  IETF.  Information  on 
the  IPSEC  working  group  and  their  work  can  be  found  at  http://www.ietf.org/html.charters/ipsec- 
charter.html 
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E.  ASYNCHRONOUS  TRANSFER  MODE 

Asynchronous  Transfer  Mode  (ATM)  is  an  emerging  transport  and  switching 
technology  for  use  in  broadband  digital  communications.  It  offers  the  possibility  of 
transmitting  a  variety  of  media  formats  at  speeds  ranging  from  a  few  megabits  per  second 
to  gigabits  per  second.  A  good  overview  of  the  technology  is  in  (Partridge,  1994)  and  an 
in-depth  discussion  can  be  found  in  (Alles,  1991).  This  section  serves  only  to  introduce 
the  reader  to  how  ATM  compares  to  the  TCP/IP  protocol  stack  and  to  provide  an 
overview  of  security  as  it  applies  to  ATM.  A  detailed  study  integrating  ATM  with  LAN 
and  WAN  connectivity  at  NPS  is  documented  in  (Courtney,  1 996). 

1.  Internet  Protocol  (IP)  and  ATM 

IP  and  ATM  are  fundamentally  different.  IP  is  a  connectionless  technology 
whereas  ATM  is  a  connection-oriented  technology.  Current  ATM  research  and  imple¬ 
mentations  focus  on  combining  existing  IP  protocols  and  immature  ATM  protocols. 
Figure  4  illustrates  how  ATM  network  services  and  protocols  roughly  map  onto  the 
TCP/IP  protocol  suite. 

The  physical  layer  in  the  ATM  protocol  model  is  still  responsible  for  bit  encoding, 
but  the  ATM  layer  combines  the  functionality  of  the  OSI  data  link  and  network  layers  for 
converting  data  link  and  higher  layer  protocols  (such  as  TCP  and  IP)  into  ATM  specific 
protocols  (Alles,  1991).  The  ATM  Adaptation  Layer  (AAL)  is  responsible  for  segmenta¬ 
tion  and  reassembly  of  the  data  stream.  The  AAL  also  handles  multiplexing  and  cell  loss 
detection  responsibilities  and  retransmission  of  lost  cells  for  connection-oriented  service. 
(Varma,  1995) 
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Figure  4.  Comparison  of  the  TCP/IP  and  ATM  models.  After  (Varma 
1995). 


2.  ATM  Security 

a.  Vulnerabilities 

ATM  can  be  implemented  over  a  variety  of  physical  media.  ATM  is 
envisioned  as  the  next-generation  broadband  digital  transmission  method,  usually  run 
using  Synchronous  Optical  Network  (SONET)  protocol  over  optical  fiber.  There  may  be 
a  tendency  to  assume  optical  fiber  is  inherently  secure.  While  it  is  true  that  some  forms 
of  attack  are  more  difficult  with  fiber  optic  links  (line  tapping  for  example),  attacks  are 
not  impossible. 

There  also  may  be  a  tendency  to  assume  that  "packet-sniffing"  is  not 
possible  in  an  ATM  network  because  ATM  is  a  connection-oriented  technology  and  cell 
switching  occurs  in  hardware  rather  than  software.  This  also  is  not  true.  ATM  is 
vulnerable  to  many  of  the  same  types  of  attack  that  have  befallen  the  Internet  community, 
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specifically  eavesdropping  (i.e.  packet/cell-sniffmg).  Cell-sniffing  was  demonstrated  by 
MCNC''  using  the  same  techniques  used  for  IP  packet-sniffing.  MCNC  connected  a 
traffic  analyzer  to  an  ATM  switch  and  captured  login  sequences  (i.e.  user  IDs  and 
passwords)  traversing  the  network  (Stevenson  et  al,  1995).  While  this  may  not  be  a 
significant  vulnerability  for  a  local-area  network  (LAN)  where  all  switching  hardware  is 
physically  controlled  by  an  organization,  it  can  be  quite  significant  for  “logical”  local- 
area  networks  (i.e.  those  sharing  the  same  address  space)  that  are  spread  over  a  wide  area, 
and  for  wide-area  networks  (WANs)  that  use  the  public  ATM  network  infrastructure 
which  is  not  controlled  by  a  single  organization.  (Pucher  et  al,  1996;  Stevenson  et  al, 
1995) 

In  addition  to  the  cell-sniffing  vulnerability,  ATM  is  vulnerable  to 
masquerading  attacks.  The  ATM  signaling  protocol  does  not  implement  a  way  to  ensure 
the  authenticity  of  a  user  accessing  a  system.  The  calling  party  ID  field  in  the  SETUP 
signaling  message  is  optional  and  is  supplied  by  the  calling  party.  The  called  party  has  no 
way  of  ensuring  the  accuracy  of  the  information  in  the  calling  party  ID  field  and  therefore 
has  no  way  of  ensuring  the  authenticity  of  the  calling  party.  (Stevenson  et  al,  1995) 

ATM  is  also  vulnerable  to  denial-of-service  attacks.  The  RESTART 
signaling  message  can  be  used  to  deallocate  bandwidth  resources  associated  with  any 


MCNC  is  a  “nonprofit  corporation  that  develops  and  applies  advanced  electronic  and 
information  technologies  for  business,  university  research,  government,  and  education  for 
economic  development”  within  North  Carolina.  MCNC  is  the  corporation’s  legal  name,  not  an 
acronym.  The  MCNC  Mission  Statement  is  available  at 
http://www.  mcnc.  org/HTML/welcome.  html 
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Virtual  Circuit  (VC)  specified  in  the  message,  including  every  active  VC  for  another  user. 
The  standard  signaling  protocol  does  not  require  proof  of  identity  for  the  user  issuing  the 
request.  (Stevenson  e/ a/.,  1995) 

b.  Proposed  Security  Services 

Recognizing  the  vulnerabilities  in  ATM,  researchers  have  recently  begim 
investigating  ways  to  include  security  services  in  the  lower-level  ATM  protocols. 
Researchers  now  recommend  that  authentication,  data  integrity,  data  confidentiality  and 
cryptographic  key  distribution  be  implemented  in  lower-level  ATM  protocol  standards. 
Proposed  ATM  security  standards  recommend  that  data  integrity  be  supported  at  the  AAL 
level  and  that  authentication,  cryptographic  key  distribution  and  confidentiality  be 
supported  at  the  ATM  layer.  It  also  is  recognized  that  these  security  services  are  required 
not  only  for  the  data  stream,  but  for  signaling  and  network  management  messages  as  well. 
(Chuang,  1995;  Peyravian  and  Herreweghen,  1995) 

Recommending  inclusion  of  data  integrity  at  the  AAL  layer  rather  than  the 
ATM  layer  is  due  to  overhead  limitations  in  the  individual  data  cells.  An  ATM  cell  is 
only  53  bytes  long;  48  bytes  for  the  data  payload  and  5  bytes  for  header  information 
(Peyravian  and  Herreweghen,  1995;  Varma,  1995;  Partridge,  1994).  Increasing  the 
header  size  to  include  an  integrity  checksum  would  necessarily  reduce  the  cell’s  data 
payload.  Such  a  change  might  result  in  an  unacceptable  reduction  in  data  throughput 
(Peyravian  and  Herreweghen,  1995). 

Recommendations  for  including  authentication,  data  confidentiality  and 
cryptographic  key  distribution  at  the  ATM  level  are  described  for  three  scenarios  in 
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(Peyravian  and  Herreweghen,  1995).  The  first  scenario  calls  for  security  services  from 
one  ATM  end-node  to  another  ATM  end-node  across  a  public  (or  private)  network.  The 
second  scenario  calls  for  security  services  from  an  ATM  end-node  to  an  ATM  switch  on 
the  border  of  a  public  (or  private)  network.  The  third  scenario  calls  for  security  services 
between  border  switches  residing  on  separate  public  (or  private)  networks.  These 
scenarios  are  shown  in  Figure  5.  (Peyravian  and  Herreweghen,  1995) 

The  specification  defining  the  proposed  security  standards  for  these 
scenarios  is  scheduled  to  be  published  by  The  ATM  Forum  in  mid  1997  (Sheth,  1996). 

(A  discussion  of  The  ATM  Forum  and  their  efforts  is  included  in  the  next  section.) 
However,  previous  experience  with  the  closed  nature  of  the  ATM  Forum  indicates  this 
estimate  may  be  optimistic.  As  a  result,  such  proposed  standards  and  corresponding 
delays  in  implementation  will  not  be  of  immediate  use  to  the  NPS  ATM  LAN.  Further¬ 
more,  even  if  the  ATM  Forum  remains  on  schedule,  the  specifications  are  likely  to  be 
incomplete  as  closed-door  security  reviews  typically  overlook  crucial  issues  that  are  only 
revealed  through  widespread  critique  and  discussion.  That  ATM  security  problems  are 
not  widespread  at  present  is  probably  due  to  the  immaturity  of  ATM  technology,  in¬ 
compatibility  among  ATM  switches  even  during  normal  operations  and  the  lack  of 
widespread  knowledge  or  use  of  ATM.  These  problems  are  documented  in  detail  in 
(Courtney,  1996).  Thus  all  aspects  of  ATM  security  need  to  be  considered  suspect  for  the 
foreseeable  future.  Interested  readers  should  consult  the  ATM  Forum  to  remain  up-to- 
date  on  current  developments. 
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(a)  Scenario  1:  end-to-end  security  services. 
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(b)  Scenario  2:  security  services  from  end-node  to  switch. 
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(c)  Scenarios:  security  services  between  switches. 


Figure  5.  Categories  of  forthcoming  proposed  security  service  implementations  ii 
ATM  networks.  After  (Peyravian  and  Herreweghen,  1995). 
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F.  RELATED  WORK 

This  section  identifies  related  research  being  conducted  in  internetworking  and 
computer  security.  Subsection  1  examines  the  impact  of  an  important  network  computing 
security  thesis  at  NFS.  Subsection  2  highlights  the  research  being  done  by  the  Informa¬ 
tion  Infrastructure  Research  Group  (IIRG)  at  NFS.  Subsection  3  provides  an  introduction 
to  the  Internet  Engineering  Task  Force  (IETF)  and  its  work.  Subsection  4  introduces  the 
ATM  Forum  and  its  research.  Subsection  5  briefly  explains  the  Information  Wide-Area 
Year  (I-WAY)  high-performance-computing  project.  A  short  discussion  of  (IFv6)  is 
presented  in  Subsection  6.  This  section  concludes  in  Subsection  7  with  a  description  of 
some  additional  related  NFS  research  projects. 

1.  Unix  System  Security  Analysis 

Unix  Security:  A  Penetration  Analysis  of  Navy  Computer  Systems  (Rich,  1992) 
examines  and  documents  vulnerabilities  associated  with  a  number  of  U.S.  Navy  net¬ 
worked  Unix  computer  systems  connected  to  the  Internet.  This  thesis  examines  six  well- 
know,  well-documented  Unix  security  vulnerabilities  and  demonstrates  the  ease  with 
which  those  vulnerabilities  can  be  exploited.  This  thesis  documents  the  results  from 
security  sweeps  of  four  Navy  commands.  While  this  thesis  does  indicate  permission  was 
obtained  from  each  command  prior  to  the  sweep,  it  does  not  indicate  if  the  responsible 
system  administration  managers  were  notified  prior  to  the  sweep.  Such  secretive  “at¬ 
tacks”  have  been  permitted  at  NFS.  If  the  purpose  of  such  secretive  “attacks”  is  to 
discover  existing  system  vulnerabilities  system  administrators  need  to  be  notified.  Even 
if  the  purpose  of  such  secretive  “attacks”  is  to  test  the  effectiveness  of  system 
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administrator  training  in  a  realistic  setting,  this  practice  unnecessarily  burdens  already 
heavily  tasked  system  administrators  since  they  can  end  up  chasing  the  proverbial  “wild 
goose”  in  their  attempts  to  isolate  and  track  down  the  intruder. 

The  strength  of  this  thesis  is  in  its  recommendations  for  a  simplistic  Unix 
security  model,  a  model  that  was  largely  ignored  until  after  the  December  1995  NFS 
security  incident.  Unfortunately  access  to  the  thesis  is  limited  to  the  DoD  and  DoD 
contractors  simply  because  it  documents  computer  system  security  vulnerabilities  even 
though  the  vulnerabilities  are  well-documented  in  other  sources,  (Curry,  1990)  for 
example.  Limiting  access  to  reports  such  as  this  is  a  misguided  attempt  at  improving 
system  security  by  keeping  quite  and  hoping  intruders  are  ignorant  about  common 
vulnerabilities.  Limiting  access  to  this  particular  thesis  no  doubt  contributed  to  the 
successful  NFS  break-in  in  December  1995. 

2.  Information  Infrastructure  Research  Group  (IIRG) 

This  thesis  is  one  of  several  master's  theses  being  'written  as  a  result  of  cooperative 
research  into  ATM  and  other  broadband  networking  technology  applications  by  the 
Information  Infrastructure  Research  Group  (IIRG)  at  NFS  (IIRG,  1996).  The  following 
sections  provide  a  brief  overview  of  other  work  being  done,  identifying  how  networked 
computer  security  applies  to  each  area  of  research. 

Automated  Local  and  Global  Network  Monitoring 
Internetworking:  Automated  Local  and  Global  Network  Monitoring 
(Edwards,  1996)  evaluates  existing  public  domain  network  monitoring  tools.  The  tools 
are  evaluated  on  IF  and  ATM  LANs  and  WANs. 
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Nenvork  monitoring  includes  the  analysis  of  message  transmission  time 
and  routing.  These  include  some  of  Ure  same  types  of  tools  used  by  Cliff  Stoll  and  his 
colleagues  a.  dte  Larurence  Berkeley  Labs  to  back  down  a  hand  of  Wes,  German  hackers 

in  the  early  1980.(8,011, 1989).  ^ust  as  Stoll  discovered  during  his  hacker  hunt,  this 

ftesis  recognizes  the  complexity  of  large-scale  intenterworks  and  the  problems  as«,cia,ed 
With  administration  and  monitoring  of  those  networks. 

A  variety  of  both  commercial  and  public-domain  tools  exist  to  aid  system 
administrators.  Unfotunately,  commercial  tools  are  prohibitively  expensive.  On  the 
other  hand,  publicdomain  software  tools  are  often  difficult  to  understand  and  use.  Tlte 


goal  of  this  thesis  is  to  integrate  various  public  domain 


software  tools  into  a  single 


automated  easy-to-use  network  monitoring  package  that  can  provide  network  administra¬ 
tors  the  network  stems  and  perfomtance  infonnation  they  need. 

Security  considerations  summarized  in  this  thesis  include  using  amomaftc 
scripts  accessible  via  home  pages  to  remotely  monitor  network  stems.  Tire  monimring 

p  can  also  automatically  e-mail  or  page  system  administrators  to  inform  them  of 
network  problems. 

b.  A  TM Local-Area  Network  (LAN) 

Ir.,ernet.ork,n,:  THe  Na.al  Pos,^adua,e  School  (NPS)  ATM l^cal-Area 
Nel^ork  (LAN)  (Courmey,  1996)  discusses  A™  LAN  configuration  and  compatibili^ 
ssues  and  documents  the  steps  taken  to  develop  a  simple  ATM  LAN  at  NPS. 

The  objective  of  this  project  is  to  create,  test  and  buUd  an  elecftonic 
information  inftastrucmre  at  NPS  based  on  ATM  cell  relay  that  will  enable  research  work 
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in  tele-education,  telescience  experiments  and  digital  interactive  multimedia.  This  thesis 
lays  the  groundwork  for  future  ATM  work  by  sending  real-time  audio,  video  and  graphics 

across  campus  and  around  Monterey  Bay  over  ATM  circuits. 

The  primary  security  considerations  highlighted  in  this  thesis  are  system 
availability  issues  associated  with  multi-vendor  hardware  and  software  incompatibility. 
This  is  a  prototype  project  and  therefore  known  security  problems  have  not  prevented 
careful  implementation,  testing  and  evaluation.  It  is  recommended  that  the  security 
vulnerabilities  and  issues  associated  with  ATM  (discussed  earlier  in  this  chapter)  will  be 

addressed  prior  to  any  operational  implementation. 

c.  Multicast  and  ATM  Network  Prerequisites  for  Distance  Learning 

Internetworking:  Multicast  and  A  TM  Network  Prerequisites  for  Distance 
Learning  (Tamer,  1996)  investigates  simple  and  cost-effective  ways  to  configure  and  use 
the  Internet  multicast  backbone  (MBone)  and  related  software  tools  to  provide  adequate 
audio  and  video  quality  over  the  Internet  as  well  as  ATM  networks  where  available.  This 
research  develops  an  inexpensive  and  easy-to-leam  method  for  implementing  and 
operating  an  MBone  classroom  facility.  This  thesis  outlines  the  steps  required  to 
configure  MBone  audio/video  recording  tools  to  allow  educational  institutions  with 
limited  budgets  (most  notably  K-12  schools)  the  opportunity  to  take  advantage  of  the 

potential  educational  benefits  offered  by  the  MBone. 

This  thesis  also  investigates  the  performance  of  multicast  transmissions 

over  ATM.  Current  MBone  tools  provide  adequate  (although  low  frame  rate)  video 
transmissions  over  the  Internet,  but  performance  is  limited  by  the  available  bandwidth. 
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Although  ATM  is  a  young  technology,  it's  high  bandwidth  and  low  latency  offers  the 
promise  of  near-real-time  broadcast  quality  audio/video  transmissions. 

Security  is  not  addressed  in  this  thesis.  However,  educators  who  are 
considering  an  MBone  implementation  must  examine  such  issues  as  hardware  access, 
system  availability,  acceptable  use  of  the  resources  and  training  to  ensure  that  resources 
are  properly  used,  so  as  not  to  degrade  the  performance  of  the  regional  and  global 
MBone. 

d.  Live  Multicast  A  udio/Video  Distribution 

Internetworking:  Using  Global  ATM  Networks  for  Live  Multicast 
Audio/Video  Distribution  (Erdogan,  1996)  documents  implementation  of  the  MBone  over 
a  regional  Frame  Relay  wide-area  network  (WAN). 

The  Monterey  BayNet  regional  Frame  Relay  WAN  links  various  K-12 
schools,  libraries,  research  and  other  educational  partners  around  the  Monterey  Bay  area, 
but  does  not  effectively  take  advantage  of  multicasting  technology  for  distance  learning 
projects.  This  thesis  documents  an  inexpensive  MBone  implementation  for  distance 
learning  over  Frame  Relay.  Despite  the  recommended  requirement  for  multicast  routers 
for  multicasting  in  a  frame  relay  network,  this  work  also  illustrates  the  feasibility  of 
implementing  multicast  service  over  Frame  Relay  without  using  multicast  routers. 

This  thesis  also  does  not  discuss  security  issues  per  se,  but  the  same  issues 
discussed  above  for  (Tamer,  1996)  apply  to  this  project.  System  availability  will  likely  be 
the  primary  concern  for  any  educational  implementation  of  the  MBone.  Proper  configu¬ 
ration  and  use  of  the  MBone  tools  will  ensure  continued  availability.  An  emphasis  on 
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training  is  required.  Additionally,  this  work  parallels  the  monitoring  work  documented  in 
(Edwards,  1 996)  in  that  automatic  scripts  accessible  via  home  page  are  used  to  monitor 
MBone  status.  Although  the  software  tools  used  in  the  scripts  typically  operate  with  root 
permissions,  software  analysis  shows  that  public  access  to  these  scripts  does  not  represent 
a  confidentiality  vulnerability.  See  Chapter  IV  for  a  general  discussion  of  these  issues. 

e.  Economical  Storage  and  Retrieval  of  Digital  Audio  and  Video  for 

Distance  Learning 

Internetworking:  Economic  Digital  Storage  and  Retrieval  of  Digital 
Audio  and  Video  for  Distance  Learning  (Tiddy,  1996)  compares  and  evaluates  existing 
digital  storage  methods  for  audio  and  video. 

While  the  Internet  already  provides  for  transmission  of  near-real-time 
audio  and  video  over  the  Internet  using  either  unicast  or  multicast  messages,  current 
audio/video  tools  for  viewing  archived  files  require  the  entire  file  be  downloaded  to  the 
local  workstation  before  it  can  be  viewed.  For  most  users  this  is  infeasible  with  large 
files.  Therefore  this  thesis  compares  and  documents  the  efficiency  of  existing  transfer 
modes,  file  formats  and  data  compression  methods  for  on-demand  audio  and  video  over 
the  Internet. 

This  thesis  also  does  not  specifically  address  security  issues.  However, 
similar  to  (Edwards,  1996)  and  (Erdogan,  1996),  this  project  implements  scripts  that  are 
accessible  via  home  pages.  The  scripts  receive  requests  to  transfer  archived  audio/video 
files  to  remote  users.  Anytime  a  server  receives  input  from  external  users  (especially  path 
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information  for  file  manipulation)  there  is  the  possibility  that  it  can  be  subverted  (Stein, 
1996). 


f.  Implementing  IPv6  in  the  Marine  Corps  Tactical  Data  Network 
Internetworking:  Technical  Strategy  for  Implementing  the  Next 
Generation  Internet  Protocol  (IPv6)  in  the  Marine  Corps  Tactical  Data  Network  (Nierle, 
1996)  describes  an  Internet  Protocol  (IP)  addressing  plan  for  use  in  the  Marine  Corps’ 
Tactical  Data  Network  (TDN).  This  thesis  discusses  the  current  Marine  Corps 
internetworking  requirements  but  also  recognizes  the  weaknesses  associated  with  the 
existing  Internet  Protocol  version  4  (IPv4)  and  the  yet-to-be--demonstrated  security 
features  of  the  next-generation  Internet  Protocol  version  6  (IPv6).^  Nierle  presents  a 
tactical  addressing  plan  for  the  TDN  that  works  with  IPv4  and  facilitates  smooth 
migration  to  IPv6  as  the  technology  matures. 

Security  considerations  summarized  in  this  thesis  include  the  need  for  data 
security  as  well  as  physical  security  of  networking  hardware.  This  thesis  also  describes 
the  enhancements  of  IPv6  over  IPv4  concerning  native  security  support  at  the  Internet  (IP) 
layer  and  improved  mechanisms  for  controlling  the  quality  of  service  (QoS). 

3.  Internet  Engineering  Task  Force  (IETF) 

The  Internet  Engineering  Task  Force  (IETF)  is  an  open  international  community 
composed  of  network  designers,  researchers,  vendors  and  users.  The  IETF  is  the 
engineering  and  protocol  development  arm  of  the  Internet.  The  IETF  is  organized  into  a 

*  IP  version  5  was  assigned  to  another  protocol  which  was  subsequently  unused 
(Huitema,  1996). 
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number  of  focus  areas,  each  with  its  own  specific  charter.  Each  focus  area  is  composed 
of  a  number  of  working  groups.  The  current  IETF  focus  areas  and  the  Security  Area 
working  groups  are  shown  in  Table  5.  (IETF,  1996) 

Chapters  V  and  VII  in  this  thesis  describe  the  Kerberos  authentication  and 
authorization  system  and  its  implementation  at  NFS.  Kerberos  is  a  secure  network  access 
mechanism  that  relies  on  a  trusted  host  to  provide  authentication  services  without  sending 
passwords  over  the  network  in  the  clear.  Work  relating  to  Kerberos  and  the  use  of  public- 
key  cryptography  for  the  initial  Kerberos  authentication  is  covered  by  the  Common 
Authentication  Technology  (CAT)  working  group.  This  group  focuses  on  providing 
protocol-independent  distributed  security  services.  Their  work  focuses  on  security 


•  Applications  Area 

•  Internet  Area 

•  Network  Management  Area 

•  Operational  Requirements  Area 

•  Routing  Area 

•  Security  Area 

o  Authenticated  Firewall  Traversal  (aft) 
o  Common  Authentication  Technology  (cat) 
o  Domain  Name  System  Security  (dnssec) 
o  IP  Security  Protocol  (ipsec) 
o  One  Time  Password  Authentication  (otp) 
o  Public-Key  Infrastructure  (X.509)  (pkix) 
o  Transport  Layer  Security  (tls) 
o  Web  Transaction  Security  (wts) 

•  Transport  Area 

•  User  Services  Area 

Table  5.  IETF  focus  areas  and  Security  Area  working 
groups  (IETF,  1996). 
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implementation  tasks  and  interfaces  rather  than  on  integrating  secimty  data  elements  into 
specific  protocols.  Mailing  list  information  for  the  CAT  working  group  follows. 

IETF  CAT  Working  Group  Mailing  List  Information: 

General  discussion:  cat-ietf@mit.edu 
To  subscribe:  cat-ietf-request@mit.edu 

Archive:  ftp://bitsy.  mit.  edu/cat-ietf/ar chive/ 

4.  The  ATM  Forum 

The  ATM  Forum  is  an  international  non-profit  organization  composed  of  over 
700  member  companies.  The  organization’s  objective  is  to  accelerate  the  use  of  ATM 
technology  through  industry  cooperation  in  protocol  and  standards  development,  as  well 
as  education  of  the  networking  and  telecommunication  community  on  the  capabilities  of 
ATM  (ATM,  1996).  The  security  working  group  within  the  ATM  Forum  was  established 
in  July  1995  for  the  purpose  of  defining  ATM  security  specifications  (Rendleman,  1995). 
The  group  is  not  expected  to  publish  a  final  version  of  A  TM  Security  Specification  (SS) 
7.0  until  mid-1997  (Sheth,  1996).  Work  completed  by  the  ATM  Forum  is  available  for  a 
fee  to  non-members.  Work  in  progress  typically  is  not  available  for  review  or  comment. 
Occasionally  ATM  Forum  development  efforts  are  performed  openly  in  cooperation  with 
IETF  working  groups. 

5.  Information  Wide-Area  Year  (I- WAY) 

The  Information  Wide-Area  Year  (I- WAY)  is  an  experimental  high-performance 
internetwork  linking  approximately  30  of  the  country's  fastest  computers  and  advanced 
visualization  environments  on  approximately  1 1  different  regional  ATM  networks.®  The 

®  Information  about  the  I- WAY  is  available  at  http://www.  iway.  org 
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I-WAY  supports  both  TCP/IP  over  ATM  and  native  ATM-oriented  protocols.  The 
supercomputers  linked  by  the  I-WAY  provide  the  resources  required  to  run  simulations  in 
a  variety  of  virtual  environments.  To  control  remote  access  to  these  resources,  the 
I-WAY  uses  the  Kerberos  authentication  and  authorization  protocol.  The  Kerberos 
implementation  at  NPS  began  as  a  class  project  to  establish  connectivity  with  other 
I-WAY  participants  during  the  Supercomputing  ‘95  conference  held  in  San  Diego 
California  in  December  1995.  (Karin,  1995) 

6.  Internet  Protocol  version  6  (IPv6) 

The  existing  Internet  Protocol  has  a  number  of  limitations  both  in  its  addressing 
structure  and  with  security  implementation  that  requires  improvements.  Internet  Protocol 
version  6  (IPv6)  is  a  designed  to  replace  the  current  Internet  Protocol  version  (IPv4). 
(Deering  and  Hinden,  1995)  The  new  version  remains  a  connectionless  protocol  but  does 
define  a  number  of  improvements  over  IPv4.  IPv6  expands  the  IP  address  size  from  32 
bits  to  128  bits  and  also  improves  multicast  message  routing.  IPv6  implements  flow 
labeling,  authentication  and  privacy  capabilities.  The  flow  labeling  capability  allows  for 
specific  quality  of  service  (QoS)  or  “real-time”  requests.  The  IPv6  specification  also 
defines  extensions  to  support  authentication,  data  integrity  and  (optional)  data  confidenti¬ 
ality.  One  active  area  of  work  is  getting  vendors  and  users  to  implement  these  extensions. 
(Huitema,  1996;  Nierle,  1996;  Deering  and  Hinden,  1995) 
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7. 


Additional  Related  NPS  Research 


a.  Integrating  the  Defense  Message  System  and  the  Global 
Broadcast  System 

Tactical  DMS:  A  Global  Broadcast  Service  Option  (Morales,  1 996) 
describes  a  means  of  integrating  the  Defense  Message  System  (DMS)  and  the  Global 
Broadcast  System  (GBS).  It  also  pertains  to  multicasting  work  being  done  by  the  IIRG. 
This  thesis  discusses  the  security  and  multicast  advantages  present  in  IPv6  and  examines 
many  of  the  same  tactical  issues  presented  in  (Nierle,  1996). 

b.  Trust  and  Interoperability  in  a  Networked  Environment 
Ensuring  a  C2  Level  of  Trust  and  Interoperability  in  a  Networked 

Windows  NT  Environment  (Lucas,  1996)  provides  an  in-depth  discussion  of  the  advan¬ 
tages,  disadvantages  and  applicability  of  the  Trusted  Computer  System  Evaluation 
Criteria  (TCSEC)  (DoD,  1985)  for  today’s  military  networks.  This  project  describes  the 
broad  scope  of  computer  security  in  today’s  computing  environment  and  emphasizes  the 
need  for  “trusted  systems”  to  ensure  confidentiality,  integrity  and  system  availability. 
This  thesis  presents  a  case  study  of  a  military  network  using  Windows  NT  version  3.51 
and  evaluates  how  effectively  this  network  operating  system  meets  the  requirements  of 
the  TCSEC. 

G.  SUMMARY 

This  chapter  provides  the  background  information  necessary  for  the  reader  to 
vmderstand  what  computer  security  is  and  why  computer  security  is  important. 
Department  of  the  Navy  AIS  security  considerations  are  discussed  and  the  (often  hazy) 
distinction  between  the  terms  threat,  vulnerability,  risk,  and  control  are  clarified. 
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Network  communication  and  security  service  functionality  concepts  within  the  ISO  OSI 
reference  model  are  discussed.  Network  communication  and  security  functionality 
associated  with  the  TCP/IP  protocol  suite  and  ATM  protocols  are  also  briefly  discussed. 
Some  of  the  vulnerabilities  associated  with  ATM  are  highlighted.  The  chapter  concludes 
with  a  broad  discussion  of  related  internetworking  and  security  research. 
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III.  PROBLEM  STATEMENT 


A.  INTRODUCTION 

There  are  two  primary  variables  that  affect  the  security  of  any  information  system: 
technology  and  people.  Technology  issues  must  address  what  security  is,  how  best  to 
implement  existing  capabilities,  and  how  to  integrate  emerging  technologies  while 
remaining  secure.  People  issues  must  address  how  much  security  is  required,  as  well  as 
who,  when,  why  and  from  where  access  to  the  computer  system/network  will  be  allowed. 
The  two  perspectives  frequently  overlap  when  new  technology  is  applied  to  support 
security.  Section  B  defines  the  two  primary  problems  this  thesis  addresses:  (1)  under¬ 
standing  the  scope  and  need  for  computer  system/network  security  for  unclassified 
systems  and  (2)  countering  the  threat  of  unauthorized  system/network  access  resulting 
from  open  and  interoperable  networks.  Section  C  briefly  describes  the  solutions  pre¬ 
sented  in  this  thesis. 

B.  PROBLEMS 

1.  Understanding  Networked  Computer  System  Security 

Networked  computer  system  security  is  a  complex  problem,  one  that  is  no  longer 
solely  restricted  to  military  or  national  security  and  associated  classified  comp\xXex 
systems  and  networks.  In  1996  there  were  over  250,000  attempted  break-ins  to  unclassi¬ 
fied  systems  within  the  Department  of  Defense  (DoD);  two-thirds  of  those  were  success¬ 
ful  (Zuckermann,  1996).  Computer/network  security  now  encompasses  a  much  wider 
scope  than  just  confidentiality  and  basic  access  controls.  Accelerating  trends  in 
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networking  requires  a  shift  in  how  managers  and  users  view  security.  Computer  and 
network  professionals  must  understand  the  scope  of  security  and  recognize  the  need  for 
security  for  even  their  unclassified  systems. 

One  tenet  of  the  IIRG  is  that  technical  problems  have  technical  solutions,  and 
people  problems  have  people  solutions.  Difficulties  often  arise  when  problems  and 
solutions  are  mismatched.  This  thesis  attempts  to  be  very  clear  in  distinguishing  whether 
problems  and  solutions  are  technology-related  or  people-related. 

AIS  security  is  primarily  a  management  issue  in  that  technical,  administrative  and 
procedural  controls  implemented  to  secure  information  systems  cost  money.  Regardless 
of  the  size  of  an  organization,  managers  control  the  money.  Managers  must  set  priorities, 
make  decisions  and  allocate  scarce  organizational  resources.  Therefore  managers  must 
ultimately  determine  the  level  of  security  required  for  any  given  system,  and  managers 
must  accept  responsibility  for  the  consequences  if  information  security  proves  inadequate. 
Of  course,  managers  are  foolish  if  they  make  decisions  without  first  examining  the  issues 
involved  in  making  those  decisions. 

The  main  challenge  with  securing  a  networked  automated  information  system  is 
recognizing  that  threats  to  AIS  security  exist  and  admitting  that  the  system  in  question  is 
not  immune  to  those  threats.  The  specific  problem  is  in  articulating  the  need  for  AIS 
security  in  the  form  of  a  quantitative  security  policy  that  is  acceptable  to  all  stakeholders. 
Managers  must  then  take  the  necessary  implementation  steps,  allocate  the  necessary 
resources  and  provide  the  necessary  support  to  carry  out  that  policy.  Proper  planning, 
analysis  and  implementation  can  ensure  a  sufficiently  secure  system. 
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2.  Open  Systems 

The  emphasis  on  open  and  interoperable  networks  has  left  many  systems  vulnera¬ 
ble  to  a  wide  variety  of  attacks.  In  a  stand-alone  computing  environment,  threats  to  AJS 
security  are  relatively  easy  to  control.  However,  once  computers  are  connected  together 
to  form  a  single  integrated  network,  which  is  then  connected  to  other  integrated  networks 
form  internetworks,  the  risks  associated  with  previously  existing  threats  are  greatly 
increased  and  new  threats  are  introduced.  Additionally,  integrating  any  new  technology 
into  an  existing  infrastructure  can  be  problematic  and  introduce  previously  unforeseen 
security  threats.  (Fraser,  1996;  Fitzgerald,  1993;  Rich,  1992) 

Transmission  of  static  passwords  in  plain  text  over  the  Internet  has  been  one  of 
the  most  vvidely  publicized  vulnerabilities  to  network  security  (CERT,  1994;  NIST,  1994; 
McNulty,  1994).  Mr.  F.  Lynn  McNulty,  the  Associate  Director  for  Computer  Security  at 
the  National  Institute  of  Standards  and  Technology  (NIST),  has  testified  before  Congress 
that  “traditional  user  authentication  by  means  of  re-useable  passwords  does  not  provide 
strong  security  in  today’s  networked  environment  -  with  or  without  encryption” 
(McNulty,  1994,  pg.  59).  The  use  of  one-time  passwords  (such  as  the  S-Key  protocol 
(Haller,  1995))  or  other  secure  remote  access  mechanism  (such  as  the  Kerberos  protocol 
(Miller,  et  al,  1987))  has  been  recommended  to  protect  against  unauthorized  access  to 
computer  systems  connected  to  the  Internet  (NIST,  1994;  McNulty,  1994;  Bennington, 
1991). 

As  a  graduate  education  and  research  institution,  the  Naval  Postgraduate  School 
(NPS)  relies  heavily  on  computer  networking  and  internetworking.  NPS  must  maintain 
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open  connectivity  with  local  and  remote  research  partners  if  it  is  to  accomplish  its 
mission.  NPS  must  also  take  the  necessary  steps  to  protect  its  systems  and  the  informa¬ 
tion  stored  on  those  systems  from  unauthorized  access.  This  is  a  precarious  balance. 
Although  an  open  environment  promotes  collaborative  research,  it  is  also  an  inviting 
target.  Therefore  security  is  necessary  if  for  no  other  reason  than  to  maintain  connectivity 
and  to  protect  research  information. 

C.  EXPERIMENTAL  SOLUTIONS 

This  thesis  examines  many  of  the  issues  that  must  be  addressed  when  assessing 
the  need  for  computer  system/network  security.  The  issues  discussed  are  used  as  a  basis 
for  a  site  security  survey  for  the  unclassified  integrated  IP/ATM  LANAVAN  in  the 
Systems  Technology  Lab  (STL)  at  NPS.  This  assessment  is  merely  a  starting  point; 
recommendations  for  additional  steps  needed  to  improve  the  state  of  security  are  in¬ 
cluded. 

To  improve  remote  plaintext  password  protection  we  implement  and  examine  the 
feasibility  of  the  Kerberos  authentication  protocol.  As  with  the  security  survey,  this  is 
merely  a  starting  point.  There  remains  much  work  to  be  done.  Nevertheless  the  results 
presented  in  this  thesis  are  promising  and  productive. 

D.  SUMMARY 

There  are  usually  two  aspects  to  any  problem:  a  social  aspect  and  a  technological 
aspect.  This  chapter  explains  the  problem  of  computer  system/network  security  from 
these  two  perspectives.  Computer  system/network  security  is  first  a  social  issue  in  that  it 
affects  people.  Managers  and  users  alike  often  do  not  understand  networked  computer 
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system  security  or  the  need  for  it,  yet  managers  are  responsible  for  ensuring  security  is 
adequate  yet  not  restrictive.  Computer  system/network  security  is  also  a  technological 
issue  for  two  reasons:  technology  often  exacerbates  the  social  issues,  and  management 
policy  concerning  system/network  security  is  often  enforced  through  the  use  of  technol¬ 
ogy.  Section  B  briefly  describes  the  two  primary  problems  associated  with  system/ 
network  security  from  these  two  perspectives  and  Section  C  lists  the  solutions  presented 
in  this  thesis  to  address  these  problems. 
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IV.  INTEGRATED  IP/ATM  LANAVAN  SECURITY  ISSUES 


A.  INTRODUCTION 

Automated  information  system  (AIS)  security  is  primarily  a  management  chal¬ 
lenge  (Walker,  1991).  This  chapter  discusses  some  of  the  issues  managers  face  when 
deciding  how  to  enhance  the  security  of  their  computer  system/network.  Security 
controls  are  not  discussed  in  detail  here  since  they  are  examined  extensively  in  a  number 
of  other  sources  (Cobb,  1992;  DoN,  1991;  Wong  and  Watt,  1990;  Palmer  and  Potter, 
1989;  Wood  et  al,  1989).  While  the  decision  outcomes  concerning  security  vary  from 
system  to  system,  the  issues  are  largely  technology-independent  and  must  be  addressed 
for  each  system.  Section  B  discusses  the  administration  issues  of  AIS  security  policies, 
plans  and  procedures.  Environmental  issues  relating  to  natural  and  human  events  are 
discussed  in  Section  C.  Software  and  data  security  issues  are  discussed  in  Section  D. 
Security  issues  associated  with  telecommunications  and  system  access  are  discussed  in 
Section  E.  Finally,  issues  concerning  security  implementation  are  discussed  in  Section  F. 

The  issues  highlighted  in  this  chapter  are  used  as  a  basis  to  assess  the  status  of 
security  associated  with  the  integrated  IP/ATM  LAN/WAN  at  NPS.  The  results  of  that 
assessment  are  presented  in  Chapter  VI. 

B.  ADMINISTRATION  ISSUES 

How  much  security  is  required?  What  types  of  controls  are  required?  These 
questions  are  not  trivial  and  must  be  answered  before  scarce  resources  are  allocated  to 
implement  any  security  controls.  Before  these  questions  can  be  answered,  system 
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administration  managers  must  identify  the  purpose  and  acceptable  uses  of  the  information 
system  in  question,  and  they  must  identify  the  individuals  who  will  be  responsible  for 
implementing  and  administering  system  security.  Furthermore,  managers  need  to 
understand  the  environment  in  which  they  are  operating  and  the  threats  such  an  environ¬ 
ment  presents.  Management  decisions  must  then  be  documented  and  disseminated  to  as 
wide  an  audience  as  possible.  Users,  system  administrators  and  other  managers  alike 
must  be  made  aware  of  these  decisions.  This  section  discusses  the  need  for  managers  to 
address  such  issues  prior  to  implementing  security  controls.  Subsection  1  discusses 
system  availability  requirements,  Subsection  2  discusses  system  security  and  acceptable 
use  policies  (AUPs)  and  Subsection  3  discusses  contingency  planning. 

1.  System  Availability  Requirements 

Protecting  against  denial  of  system  service  is  one  of  the  basic  goals  of  computer 
system/network  security.  (See  the  definition  of  AIS  security  in  Chapter  II.)  It  also  is 
probably  the  most  difficult  goal  to  achieve.  Like  many  other  aspects  of  system/network 
security,  protecting  system  services  is  itself  a  multifaceted  problem.  Nevertheless  system 
availability  must  be  addressed  because  an  information  system  is  useless  if  users  caimot 
get  or  use  the  system  resources  they  need. 

One  of  the  primary  issues  that  will  determine  the  amount  of  security  required  for 
an  information  system  is  the  importance  of  the  system  and  the  information  it  processes. 
System  availability  requirements  (i.e.  maximum  allowable  down  time)  will  vaiy  accord¬ 
ing  to  this  assessment  and  must  be  clearly  understood.  A  critical  system  may  have  a  99% 
(or  greater)  availability  requirement  (e.g.  down  time  not  to  exceed  15  minutes  in  a  24 
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hour  period),  whereas  a  secondary  or  noncritical  system  may  be  able  to  accommodate 
much  longer  down  times.  (Buddenberg,  1995;  Russell  and  Gangemi,  1991;  Wong  and 
Watt,  1990) 

Of  related  interest  is  the  ongoing  lack  of  any  system  availability  requirement  for 
NFS,  recently  demonstrated  by  a  3-week  “security  shutdown”  of  all  networked  computing 
systems  in  late  1995.  This  occurred  despite  the  fact  that  one  of  the  major  goals  of  the 
NFS  Automated  Data  Frocessing  Security  Frogram  (NFS,  1992)  is  to  “minimize  the 
denial  of  ADF  services  to  authorized  users  which  might  occur  as  a  result  of  unauthorized 
access,  operator  error,  power  disruption,  malicious  acts,  etc.”  (NFS,  1992,  pg.  2). 
Repercussions  of  such  shutdowns  jeopardize  the  operations,  mission  and  long-term 
viability  of  the  school. 

Threats  to  system  availability  are  not  limited  strictly  to  the  environmental, 
telecommunications  or  system-access  threats  discussed  later  in  this  chapter.  Restricted 
computing  center  operating  hours,  inadequate  help  facilities  (human  or  automated),  and 
even  inadequate  memory,  disk  space  or  other  resources  can  also  lead  to  denial  of  service. 
While  a  complete  discussion  of  how  to  determine  system  availability  requirements  is 
beyond  the  scope  of  this  work,  managers  must  carefully  consider  such  requirements 
before  any  security  controls  are  implemented.  Without  a  careful  analysis  of  system 
availability  requirements,  managers  are  unable  to  evaluate  the  cost  effectiveness  of  the 
various  controls.  (Buddenberg,  1995;  Russell  and  Gangemi,  1991;  Wong  and  Watt, 

1990) 
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2.  System  Security  and  Acceptable  Use  Policies  (AUPs) 

Before  managers  can  determine  how  much  and  what  type  of  security  controls  to 
implement  for  any  given  AIS,  they  must  determine  their  goals  and  priorities  concerning 
security  for  the  organization  and  that  system.  This  determination  constitutes  an  organiza¬ 
tion’s  AIS  security  policy  which  clearly  outlines  "the  set  of  rules,  principles  and  proce¬ 
dures  that  regulate  how  an  organization  manages,  protects,  and  controls  . . .  computer 
resources  and  the  information  they  contain"  (Cobb,  1992,  pg.  111).  The  system  security 
policy  needs  to  clearly  describe  organizational  priorities  and  philosophy  concerning  AIS 
security.  This  policy  must  be  explained  through  training  and  distributed  freely  throughout 
the  organization.  (Fraser,  1996;  Cobb,  1992;  Russell  and  Gangemi,  1991;  Wong  and 
Watt,  1990) 

A  security  philosophy  will  fall  somewhere  on  the  continuum  between  "denying 
all"  system/network  access  and  services  and  "allowing  all"  system/network  access  and 
services  (Fraser,  1996;  Russell  and  Gangemi,  1991).  This  is  the  fundamental  dichotomy 
in  the  protection  against  denial  of  system  services.  A  “deny  all”  policy  will  almost 
certainly  eliminate  unauthorized  access  but  will  also  undoubtedly  deny  use  of  required 
services  to  otherwise  legitimate  users.  Conversely  an  “allow  all”  policy  will  give  users 
access  to  all  required  services  but  will  also  make  those  same  services  vulnerable  to  a 
denial-of-service  attack.  Therefore,  policy  decisions  will  reflect  trade-offs:  trade-offs 
between  the  available  computing  services  offered  and  the  amount  of  security  provided; 
trade-offs  between  the  ease  of  system  use  and  the  sophistication  of  security  controls;  and 
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trade-offs  between  the  AIS  security  costs  (both  tangible  and  intangible)  and  the  risk  of 
loss  if  a  security  incident  occurs  (Fraser,  1996). 

The  organization's  acceptable  use  policy  (AUP)  for  information  resources  is 
closely  related  to  system  availability  and  may  be  an  integral  part  of  the  system  security 
policy  (Fraser,  1996).  Automated  information  systems  represent  a  large  investment  for 
most  orgamzations  and  are  usually  employed  in  a  multi-user  environment.  In  such  an 
environment,  there  is  always  the  temptation  for  individual  users  to  abuse  or  otherwise  use 
the  system  resources  either  unproductively  or  inefficiently.  If  resources  are  being  used 
for  nonproductive  or  illegitimate  purposes,  they  are  unavailable  for  other  users  with 
legitimate  and  productive  computing  to  accomplish.  Borrowing  a  concept  from  economic 
theory,  if  users  are  not  held  personally  responsible  for  their  use  of  the  resources,  it  is 
conceivable  that  the  system  might  suffer  a  "tragedy  of  the  commons."  Such  a  situation 
occurs  when  communal  resources  are  depleted  through  overuse  or  abuse  by  individuals 
who  do  not  have  a  personal  stake  in  the  resource  (Heyne,  1994).  From  a  security  stand¬ 
point,  imauthorized  use  of  information  systems  may  present  additional  or  unanticipated 
security  threats  to  the  system.  Therefore  managers  must  establish  explicit  acceptable  use 
policies  (AUPs).  These  administrative  policies  seek  to  ensure  that  the  computing 
resources  are  used  effectively  and  efficiently.  Although  NFS  does  have  a  campus-wide 
AUP  (NPS,  1995),  it  shares  the  same  problems  of  effectiveness  and  enforceability 
associated  with  any  administrative  policy.  Users  are  not  explicitly  instructed  or  briefed 
on  the  AUPs  nor  are  they  required  to  sign  a  statement  affirming  acceptance  of  the 
policies. 
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3.  Contingency  Planning 

No  matter  how  much  money  an  organization  spends  on  IS  security  or  how  many 
controls  are  in  place,  disasters  and  security  incidents  can  still  occur.  The  actions  an 
organization  will  take  following  such  an  occurrence  must  be  planned  and  documented 
well  in  advance;  it  does  little  good  (indeed  it  harms  legitimate  users)  to  lock  one's  front 
door  after  the  thief  has  come  and  gone.  These  contingency  plans  must  contain  specific 
actions  an  organization  will  take,  not  only  to  react  to  a  security  incident  or  disaster  but  to 
recover  from  it  as  well.  (Fraser,  1996;  Fitzgerald,  1993;  Cobb,  1992)  The  recovery 
actions  outlined  in  the  contingency  plans  will  depend  largely  on  the  system  availability 
requirements  discussed  above,  therefore  it  is  imperative  that  managers  identify  those 
requirements  first  (Palmer  and  Potter,  1989).  NPS  directives  mandate  that  a  contingency 
plan  “be  developed  for  each  AIS  where  a  disruption  of  service  would  have  a  critical 
impact  on  mission  accomplishment”  (NPS,  1992).  Such  a  plan  dos  not  exist  and  is  not  in 
wide  use  at  NPS  (Franklin,  1996;  Norman,  1996). 

Contingency  planning  is  closely  coupled  with  risk  analysis  and  should  include 
procedures  for  recovering  from  all  threats  to  system  security,  not  simply  those  presented 
by  the  environment.  While  it  is  important  to  have  procedures  in  place  in  the  event  of  a 
fire,  flood,  or  power  outage,  it  is  equally  important  to  plan  for  unanticipated  hardware  or 
software  failures  (such  as  a  hard  disk  crash  or  software  bug)  and  for  malicious  acts  (such 
as  a  network  virus  or  unauthorized  network  access).  The  more  familiar  personnel  are 
with  the  contingency  procedures,  the  faster  the  response  is  likely  to  be,  quite  possibly 
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reducing  the  impact  of  the  incident.  (Fraser,  1996;  Cobb,  1992;  Wong  and  Watt,  1990; 
Palmer  and  Potter,  1989) 

4.  Roles  and  Responsibilities 

AIS  security  roles  and  responsibilities  for  all  personnel  —  managers,  administra¬ 
tors,  techmcians  and  users  —  must  be  clearly  documented  and  the  affected  personnel 
must  be  aware  of  (and  intimately  familiar  with)  the  detailed  requirements  for  their  respec¬ 
tive  roles  and  responsibilities.  AIS  security  responsibilities  are  often  assigned  to  system 
administrators  in  addition  to  other  roles  and  responsibilities.  While  this  is  not  in  itself 
unsatisfactoiy,  managers  must  ensure  that  appropriate  priority  is  given  to  the  security 
responsibilities.  As  seen  in  Table  6,  AIS  security  is  a  complex  field  with  a  great  many 
roles  and  responsibilities  that  must  be  accomplished.  Although  some  of  these  responsibil¬ 
ities  will  not  apply  to  all  organizations,  it  is  easy  to  understand  why,  even  in  a  small 
organization,  AIS  security  requirements  may  quickly  overwhelm  even  the  most  efficient 
system  administrator.  This  is  especially  since  most  system  administrators  are  already 
heavily  tasked.  If  AIS  security  truly  is  a  priority,  managers  must  ensure  adequate 
resources  are  allocated  to  satisfy  that  priority.  (Fitzgerald,  1993;  Cobb,  1992;  Wong  and 
Watt,  1991)  NPS  AIS  “corporate”  security  roles  and  responsibilities  are  outlined  in 
(NPS,  1992).  Additional  roles  and  responsibilities  may  be  assigned  on  an  individual 
departmental  basis. 

C.  ENVIRONMENTAL  ISSUES 

Effective  and  efficient  security  controls  cannot  be  implemented  without  a  clear 
understanding  of  the  physical  environment  in  which  an  AIS  is  operating.  Automated 
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•  corporate  IT  security  policy 

•  security  of  data  center,  communication  network  and  terminals 

•  liaison  with  computer  users 

•  production  and  enforcement  of  security  standards  and  procedures 

•  Data  Protection  Act  compliance 

•  risk  analysis  and  monitoring 

•  implementation  and  administration  of  access  control  equipment  and  software 

•  control  of  encryption  and  authentication  devices 

•  contingency  planning  and  computer  insurance 

Table  6.  IS  security  roles.  From  (Wong  and  Watt,  1991,  pp.  128-129). 


information  systems  are  susceptible  to  a  great  many  environmental  hazards  broadly 
classified  as  either  a  product  of  nature  (e.g.  earthquakes  or  floods)  or  a  product  of  humans 
(e.g.  intentional  or  accidental  damage  or  destruction  of  equipment).  Some  environmental 
threats  (unstable  electrical  power  and  fire,  for  example)  can  be  caused  either  by  nature  or 
by  man,  but  in  such  cases  it  usually  does  not  matter  how  such  disasters  are  caused  since 
the  end  results  are  identical.  Therefore  the  controls  to  counter  these  threats  are  likely  to 
be  identical.  Natural  threats  are  briefly  discussed  in  Subsection  1  and  human-induced 
threats  are  discussed  in  Subsection  2. 

1.  Natural  Disasters 

While  often  improbable,  natural  disasters  are  still  quite  possible.  Threats  in  this 
category  include  not  only  familiar  threats  such  as  fires,  floods,  unstable  electrical  power 
and  static  electricity  shocks,  but  also  such  uncommon  threats  as  earthquakes,  tsunamis 
and  acts  of  war.  Of  course  each  site  will  have  its  own  unique  collection  of  threats. 
Controls  in  this  category  include  but  are  not  limited  to:  sprinkler  systems,  surge  protec¬ 
tors  or  uninterruptible  power  supplies,  anti-static  carpeting,  placing  hardware  on  raised 
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platforms,  plastic  sheets  or  covers  to  protect  hardware  from  falling  water,  and  tempera¬ 
ture/humidity  monitors  to  warn  against  excessive  heat  or  humidity.  (Palmer  and  Potter, 
1989;  Wood  et  al.,  1987)  Minimum  measures  for  protection  against  environmental 
threats  are  outlined  in  Appendix  B  of  (NPS,  1 992). 

2.  Human  Disasters 

Human  disasters  can  be  either  accidental  or  intentional.  Controls  for  intentional 
human  threats  typically  focus  on  physical  access  security  to  protect  against  outside 
intruders.  Hardware  is  locked  up  or  access  is  otherwise  controlled  using  a  number  of 
different  mechanisms,  ranging  from  simple  escort  procedures,  access  control  lists  and 
identification  badges  to  more  sophisticated  equipment  such  as  magnetic  strip  smart  cards 
or  biometric  identification  devices  (e.g.  finger  print  readers  or  retinal  scanners).  How¬ 
ever,  most  human  induced  disasters  are  caused  by  internal  personnel;  authorized  system 
users  are  far  more  likely  to  cause  damage  to  the  system  than  any  external  threat 
(Baskerville,  1989). 

While  disgruntled  employees  are  a  legitimate  threat  to  system  security,  most 
damage  caused  by  insiders  is  unintentional.  The  disgruntled  employee  threat  can  be 
minimized  by  good  personnel  security  and  proactive  leadership.  Accidental  damage  can 
be  minimized  through  adequate  administrative  policies,  consistent  enforcement  of  those 
policies  and  adequate  training.  Additionally,  software  can  provide  simple  automatic 
monitoring  capabilities  with  system  status  results  available  via  home  page  and  electronic 
mail  (Edwards,  1996;  Erdogan  1996). 
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D.  SOFTWARE  AND  DATA  ISSUES 


As  costly  as  computer  hardware  may  be,  the  most  valuable  asset  associated  with  a 
computer  system/network  is  usually  the  data  and  information  it  processes.  This  section 
discusses  software  and  data  security  issues.  Configuration  management  issues  are 
discussed  in  Subsection  1 ;  integrity  and  confidentiality  issues  are  discussed  in  Subsection 
2;  the  need  for  system  backups  is  in  Subsection  3. 

1.  Configuration  Management 

Configuration  management  is  the  process  of  "identifying,  controlling,  accounting 
for,  and  auditing  all  changes  made  to  the  baseline  TCB  [trusted  computing  base], 
including  hardware,  firmware,  and  software  . . ."  (Russell  and  Gangemi,  1991,  pg.  145). 
As  implied  in  the  definition  above,  the  term  “configuration  management”  is  often 
reserved  for  use  vwth  trusted  systems  (e.g.  systems  that  process  classified  information), 
yet  it  is  equally  applicable  to  those  systems  processing  and  storing  only  unclassified  or 
nonsensitive  data.  Improper  system  configuration  or  imperfect  integration  of  application 
software  can  weaken  system  security.  New  application  software  releases  can  introduce 
additional  security  holes  (CERT,  1996a;  CERT,  1996b).  Removing  old  or  unneeded 
software  not  only  simplifies  file  management  but  also  avoids  possible  configuration 
conflicts  with  new  software.  Outdated  operating  system  software  with  known  security 
holes  also  must  be  updated  with  the  latest  software  patch  and  old  versions  deleted  from 
the  system.  System  administrators  must  remain  informed  and  take  the  necessary  steps  to 
minimize  newly  discovered  threats  and  vulnerabilities  of  system  and  application  software. 
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(Fraser,  1996;  Curry,  1990;  Rich,  1992)  General  configuration  management  require¬ 
ments  for  NFS  are  outlined  in  (NFS,  1992). 

2.  Integrity  and  Confidentiality 

Integrity  and  confidentiality  of  stored  data  can  be  protected  using  cryptographic 
checksums  and  bulk  file  encryption,  but  the  primary  means  for  protecting  data  integrity 
and  confidentiality  while  it  is  stored  and  processed  on  an  AIS  is  through  data  access 
controls.  (Data  integrity  and  confidentiality  during  transmission  over  network  connec¬ 
tions  is  discussed  in  Section  E.)  While  physical  access  controls  indirectly  protect  against 
data  modification,  destruction  and  disclosure  by  disallowdng  imauthorized  access  to  the 
hardware  components,  data  access  controls  directly  protect  against  data  modification, 
destruction  and  disclosure  by  disallowing  unauthorized  access  to  the  software  and  data 
files. 

Sensitivity  of  the  data  will  determine  whether  discretionary  access  controls  (DAC) 
or  mandatory  access  controls  (MAC)  are  required.  DAC  allow  users  to  set  access 
permissions  on  their  own  files  as  they  wish  (e.g.  the  standard  Unix  file  permissions). 
MAC  are  set  and  enforced  by  the  AIS  operating  system  security  kernel  based  on  security 
labels  assigned  to  system  objects  (e.g.  files,  directories,  processes  and  users)  in  accor¬ 
dance  with  the  organization’s  security  policy.  In  the  latter  case,  users  do  not  have 
complete  control  over  how  the  permissions  are  set.  MAC  is  used  typically  in  multilevel 
security  environments.  (Russell  and  Gangemi,  1991;  DoD,  1985)  The  NFS  ADF 
Security  Frogram  directive  (NFS,  1992)  does  not  address  general  data  confidentiality  and 
integrity  policies  for  unclassified  computing  systems. 
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3.  System  Backups 

System  hardware  is  usually  replaced  rather  easily,  although  often  at  considerable 
one-time  cost.  The  same  caimot  always  be  said  about  the  data  that  is  stored  on  a  system; 
data  is  often  priceless  or  is  not  reproducible.  Data  and  software  are  vulnerable  to  a 
variety  of  threats  that  include  viruses  or  other  malicious  software,  disgruntled  or  un¬ 
trained  employees,  and  hardware  failure  (e.g.  a  hard  disk  crash).  The  easiest  control 
against  unintentional  or  malicious  modification  or  destruction  of  data  is  to  conduct 
adequate  system  backups.  System  backups  must  also  be  stored  securely  to  ensure  they 
themselves  are  not  damaged  or  otherwise  corrupted  in  the  event  of  an  incident.  Backups 
must  be  a  true  representation  of  the  system  state  before  the  incident.  (Fraser,  1996;  NFS, 
1992;  Russell  and  Gangemi,  1991;  Wong  and  Watt,  1990) 

Again,  the  importance  of  the  data  stored  on  the  system  will  determine  the 
frequency  of  the  backups.  The  organization  will  want  to  backup  critical  data  much  more 
often  than  noncritical  data,  but  even  noncritical  data  needs  to  be  backed  up  periodically. 
Although  it  is  wise  for  users  in  a  multi-user  environment  to  maintain  personal  backup 
copies  of  their  files,  this  is  often  infeasible  due  to  classification  or  large  file  sizes. 
Therefore  it  is  appropriate  for  users  to  expect  the  computing  services  staff  to  conduct 
regular  file  system  backups  that  include  even  noncritical  user  data.  The  organization’s 
backup  policy  must  consider  user  expectations  and  must  also  be  documented  and  widely 
distributed  within  the  organization.  NFS  backup  policy  is  documented  in  (NFS,  1992) 
and  explicitly  states  that  users  are  responsible  for  their  own  data  files.  Individual  system 
backup  requirements  vary  depending  on  the  classification  of  information  that  is  processed 
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or  stored  on  each  individual  system  (NPS,  1992).  While  there  is  some  disagreement 
between  the  users  and  administrators  concerning  the  adequacy  of  the  NPS  backup 
policies,  the  policies  are  widely  followed. 

E.  TELECOMMUNICATIONS  AND  SYSTEM  ACCESS  ISSUES 

Managers  must  consider  telecommimications  and  system  access  issues  when 
determining  system  security  requirements.  Subsection  1  discusses  network  access 
controls.  Subsection  2  discusses  the  concepts  of  identification,  authentication  and 
authorization.  Subsection  3  discusses  the  notion  of  nonrepudiation.  Subsection  4 
discusses  data  confidentiality  and  integrity  with  regards  to  network  communications. 
Subsection  5  discusses  issues  relating  to  network  coimectivity. 

1.  Access  Control 

Network  access  security  is  arguably  the  most  important  and  most  challenging 
facet  of  AIS  security  given  today’s  computing  environment.  Every  unprotected  network 
port  is  an  open  door  into  the  system.  As  with  system  availability  requirements,  network 
access  security  is  multifaceted.  It  concerns  not  only  physical  access  to  system  compo¬ 
nents  (i.e.  the  network  infrastructure)  and  access  to  data  and  software  as  discussed  above, 
but  also  telecommimications  access.  Intruders  may  gain  access  to  a  network  through 
telecommunications  networks  to  manipulate  the  data  or  software.  NPS  access  control 
policy  is  to  grant  access  to  only  those  systems  and  data  an  individual  needs  to  accomplish 
assigned  tasks.  This  policy  is  specified  in  (NPS,  1992).  The  general  policy  is  widely 
followed  but  specific  procedures  for  implementing  the  policy  are  left  to  the  discretion  of 
individual  network  managers. 
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The  first  line  of  defense  for  network  access  security  is  controlling  physical  access 
to  system  hardware  components  (i.e.  the  network  infrastructure)  including  workstations, 
network  cabling,  disk  drives,  communication  routers  and  network  switches.  Although 
controlling  access  to  private  network  components  through  routine  physical  security 
mechanisms  is  relatively  straightforward,  controlling  access  to  the  public  infrastructure  is 
not  possible.  Public  routers  and  switches  can  be  subverted;  an  intruder  can  eavesdrop  on 
network  traffic  by  tapping  cables  and  wires  or  by  gaining  access  to  network  switches  and 
routers  and  reconfiguring  the  routing  tables  to  misroute  data  packets.  Public  networks  are 
outside  the  realm  of  responsibility  of  the  organization  and  must  not  be  trusted.  (Kluepfel, 
1996) 

A  physically  secure  network  does  not  guarantee  network  security.  Modem 
computer  networks  are  typically  protected  fi-om  unauthorized  telecommunications  access 
by  a  filtering-router  firewall.  Filtering-router  firewalls  examine  the  source  IP  address  of 
incoming  data  packets  and  filter  out  those  packets  with  IP  addresses  that  are  not  autho¬ 
rized  access  to  the  network.  Unfortunately  the  source  IP  address  of  incoming  data 
packets  can  be  altered  by  an  intmder  to  fool  a  firewall  into  allowing  otherwise  unautho¬ 
rized  packets  access  to  the  network.  This  type  of  attack  is  called  “address-spoofing.”  A 
number  of  spoofing  methods  are  documented  in  (Bellovin,  1989).  Once  the  firewall  has 
been  breached  the  network  applications  that  use  source  IP  addresses  for  authentication  are 
vulnerable  to  the  same  form  of  attack.  (CERT,  1995;  Bellovin,  1989) 
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The  cracker”  (or  “hacker”)’  threat  has  been  widely  publicized  in  recent  years.  In 
1996,  unclassified  DoD  computer  systems  were  attacked  an  estimated  250,000  times  with 
nearly  two-thirds  of  those  attacks  being  successful  (Zuckermann,  1996).  “Cracker” 
attacks  include  attacks  on  the  network  infrastructure  as  well  as  attacks  against  the 
software  and  data.  These  attacks  include  password-sniffing  attacks,  address-  spoofing 
attacks  and  denial  of  service  attacks.  Most  successful  attacks  exploit  well-known,  well- 
documented  system  vulnerabilities.  Therefore  it  is  imperative  that  system  administrators 
remain  informed  about  and  attempt  to  remedy  system  vulnerabilities.  Of  course  it  is 
important  to  note  that  system  administration  personnel  must  expend  valuable  time  and 
resources  to  remain  current.  Like  most  security  issues,  there  is  a  tradeoff.  (Kluepfel, 
1996;  Haller,  1994;  Rich,  1992) 

2.  Identification,  Authentication  and  Authorization 

The  next  line  of  defense  in  network  access  security  is  identification,  authenti¬ 
cation  and  authorization.  Identification  verifies  the  existence  of  a  particular  user. 
Authentication  verifies  the  user  is  actually  who  they  claim  to  be.  Authorization  verifies 
the  user  is  allowed  access  to  particular  system  services.  These  three  network  security 
functions  form  the  foimdation  of  all  AIS  security;  an  intruder  cannot  gain  access  to  an 
AIS  unless  they  subvert  all  three  fimctions.  Controlling  access  to  the  public  network 


The  terms  hacker  and  cracker  are  somewhat  ambiguous  and  greatly  debated. 
(Russell  and  Gangemi,  1991)  defines  a  hacker”  as  an  individual  with  a  keen  interest  in  computer 
systems  and  an  eagerness  to  experiment  with  them  and  test  their  limits.  They  define  a  “cracker” 
as  an  individual  who  intentionally  breaks  into  computer  systems  with  malicious  intent. 
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infrastructure  is  the  ideal  first  step  in  network  access  security  that  is  not  feasible. 

Therefore  identification,  authentication  and  authorization  become  the  first  line. 

The  first  objective  of  most  attacks  on  a  system  is  to  gain  access  to  the  data.  To 
successfully  gain  access  an  attacker  need  only  determine  the  user  ID  and  password  for  a 
single  user  on  the  system.  Unfortunately  users  are  notorious  for  choosing  poor  passwords 
or  are  careless  in  protecting  them.  Conversely,  “good”  passwords  are  difficult  to 
remember  which  introduces  additional  insecurities  when  users  write  down  their  pass¬ 
words  or  are  unable  to  access  the  system  when  they  forget  their  passwords.  Common 
techniques  for  obtaining  passwords  include  “social  engineering”  (e.g.  impersonating  a 
system  administrator  over  the  telephone)  (Winkler,  1995),  exploiting  operating  system 
vulnerabilities  to  gain  access  to  the  system  password  file,  installing  a  Trojan  Horse*  on  a 
networked  workstation  to  transmit  login  sequences  to  the  intruder,  and  capturing  unen¬ 
crypted  remote  login  sequences  by  “sniffing”  data  packets  while  eavesdropping  on  remote 
network  connections.  One  of  the  most  significant  dangers  associated  with  static  multi¬ 
use  passwords  is  that  it  usually  is  not  possible  to  detect  or  know  when  a  particular 
password  has  been  compromised. 

In  general,  using  static  passwords  has  been  greatly  criticized  by  law  enforcement, 
academic  and  government  experts.  These  experts  recommend  implementing  a  dynamic 
password  scheme  such  as  Bellcore’s  S-Key  protocol  (Haller,  1995)  or  other  secure  access 

*  A  Trojan  Horse  is  a  computer  program  or  code  fragment  that  “hides  in  an  independent 
program  that  performs  a  usefiil  or  appealing  function  —  or  appears  to  perform  that  function. 
Along  with  the  apparent  function,  however,  the  program  also  performs  some  other  unauthorized 
operation”  (Russell  and  Gangemi,  1991,  pg.  83). 
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mechanism  such  as  MIT’s  Kerberos  protocol  (Miller  et  al,  1985).  Implementing  a 
second  authentication  mechanism  such  as  a  magnetic  smart  card  or  a  biometric  device 
such  as  a  fingerprint  reader  will  greatly  increase  system  and  network  access  security. 
(McNulty,  1994;  NIST,  1994;  Bermington,  1991) 

3.  Nonrepudiation 

Nonrepudiation  is  the  process  of  protecting  against  denial  of  receipt  or  transmis¬ 
sion  of  data  by  the  receiver  or  sender  respectively.  As  the  commercial  use  of  the  Internet 
continues  to  expand,  nonrepudiation  will  become  increasingly  important.  Electronic 
commerce  will  require  nonrepudiation  mechanisms  to  protect  the  interests  of  both 
suppliers  and  consiuners.  This  will  require  some  form  of  cryptography.  Many  current 
nonrepudiation  mechanisms  are  based  on  the  Digital  Signature  Standard  (DSS)  (NIST, 

1992) .  There  are  many  issues  and  concerns  that  still  must  be  resolved  before  nonrepudi¬ 
ation  mechanisms  are  widely  implemented.  The  greatest  of  these  include  whether  to  use 
secret-key  cryptography  or  public-key  cryptography,  how  to  distribute  and  manage  the 
cryptographic  keys,  what  control  an  organization  will  exercise  over  its  employees'  keys, 
what  role  government  will  play  in  the  process  and  what  impact  cryptographic  software 
export  restrictions  will  have  on  the  organization.  These  issues  will  need  to  be  addressed 
in  the  organization's  information  security  policy.  (Carpenter  and  Baker,  1996;  Fahn, 

1993)  Nonrepudiation  policies  are  currently  uncommon  due  to  lack  of  consensus  on 
technical,  administrative  and  economic  issues. 
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4.  Integrity,  Confidentiality  and  Authenticity 

Because  securing  the  network  “pipe”  is  infeasible  in  today’s  interconnected 
networking  environment,  we  must  secure  the  data  in  the  “pipe”  if  data  security  is 
required.  Confidentiality  during  network  transmission  can  be  sufficiently  assured  by 
using  a  bulk  encryption  protocol  such  as  DBS  (NIST,  1988)  or  RSA  (Rivest  et  al,  1978). 
If  encryption  is  done  below  the  network  layer,  intermediate  nodes  within  the  network 
must  be  able  to  decrypt  the  data  packet  to  find  where  it  next  needs  to  be  routed.  This 
slows  delivery  and  also  provides  the  opportunity  for  an  intruder  with  access  to  an 
intermediate  node  to  view  the  packet  contents.  Encrypting  the  data  packets  at  the 
application  layer  guards  against  this  possibility,  but  also  opens  the  door  for  intruders  to 
analyze  traffic  flow  between  nodes  (i.e.  packet  frequency,  size,  addressees  etc.)  with  the 
hope  of  piecing  together  useful  information.  Just  as  with  most  decisions  concerning  AIS 
security,  there  are  many  tradeoffs. 

Data  integrity  during  network  transmissions  can  be  sufficiently  assured  using 
cryptographic  checksums  or  message  digests  such  as  MD5  (Rivest,  1992)  or  the  secure 
hash  algorithm  (SHA)  portion  of  the  DSS  (NIST,  1992).  Similarly,  data  authenticity  can 
be  sufficiently  assured  using  digital  signatures  such  as  those  provided  by  the  DSS  or  PGP 
(Zimmerman,  1994). 

5.  Network  Connectivity 

Besides  the  physical  security  of  network  cabling  and  hardware,  there  are  three 
connectivity  variables  in  which  we  are  interested.  The  first  variable  is  the  type  of  hosts  to 
which  we  are  connecting.  The  security  challenges  present  when  connecting  similar  hosts 
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(e.g.  ATM-to-ATM  or  IP-to-IP)  may  be  different  than  when  eonnecting  dissimilar  hosts 
(e.g.  ATM-to-IP).  The  seeond  variable  is  the  connection  method.  The  security  chal¬ 
lenges  when  remotely  connecting  to  a  network  over  the  Internet  may  be  different  than 
when  remotely  connecting  to  a  network  using  direct-dial  telephone  lines.  The  third 
variable  is  the  message  address.  Messages  with  multicast  addresses  may  be  vulnerable  to 
different  security  challenges  than  messages  with  unicast  addresses.  We  examine  these 
network  connectivity  issues  in  detail. 

a.  Similar  versus  Dissimilar  Hosts 

Much  current  work  focuses  on  running  IP  and  other  higher-layer  protocols 
over  ATM  in  addition  to  native  ATM-to-ATM  connections.  This  hybrid  approach 
theoretically  permits  the  use  of  TCP/IP  firewalls  to  protect  a  network.  However,  native 
cell-based  ATM  environments  cannot  use  IP  packet  filters  because  protocol  differences 
are  too  great  (Rendleman,  1995).  Nevertheless  research  is  being  performed  in  the  area  of 
ATM  firewalls  (Chuang,  1995;  Raynovich,  1995).  One  approach  recommends  filtering 
only  the  call  setup  cells  (Chuang,  1995).  Another  proposed  solution  combines  hardware 
and  software  and  promises  to  filter  each  cell  without  slowing  down  the  data  rate 
(Raynovich,  1995).  In  either  case,  for  hosts  connected  to  both  an  internal  Ethernet  LAN 
and  an  external  ATM  WAN,  there  is  little  assurance  (other  than  protocol  complexity,  a 
dubious  safeguard)  that  an  intruder  will  not  come  through  an  ATM  port,  exploit  a  system 
vulnerability  and  then  gain  access  to  the  internal  IP  network  (Rendleman,  1995). 
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b.  Internet  versus  Direct-dial  Telephone  Lines 
The  Internet  is  an  open  environment  and  various  insecurities  have  been 
discussed  throughout  this  work.  As  mentioned  above,  most  Internet  attacks  attempt  to 
exploit  well-known,  well-documented  system  vulnerabilities.  While  patches  are  available 
for  most  of  these  vulnerabilities,  it  is  essentially  impossible  that  all  nodes  have  the  latest 
patch;  there  will  always  be  a  hole  somewhere  in  the  net.  It  is  unwise  for  organizations  to 
trust  or  expect  Internet  Service  Providers  (ISPs)  to  provide  security  for  data  transmitted 
over  the  Internet  regardless  of  what  the  underlying  network  infrastructure  looks  like. 

Since  the  Internet  is  not  an  inherently  secure  environment,  it  is  similarly  unlikely  that  a 
public  ATM  network  will  be  a  particularly  secure  environment. 

Direct-dial  telephone  lines  are  safer  but  are  still  vulnerable.  Communica¬ 
tion  networks  are  weakly  protected  and  particularly  susceptible  to  human  interference. 

The  following  quote  from  an  IETF  draft  copy  of  National  Information  Infrastructure  Risk 
Assessment:  A  Nation  at  Risk  as  quoted  in  (Bollentin,  1996)  demonstrates  the  vulnerabil¬ 
ity  quite  well. 

Within  the  PSN  [public  switched  network],  intruders  have  already  com¬ 
promised  nearly  all  categories  of  activities,  from  switching  systems  to 
operations,  administration,  maintenance,  and  provisioning  (OAM&P) 
systems,  and  to  packet  data  networks.  Private  branch  exchanges  and 
corporate  networks  that  tie  into  the  public  network  have  crashed  or  dis¬ 
rupted  signal  transfer  points  (STPs),  traffic  switches,  OAM&P  systems, 
and  other  network  elements.  They  have  planted  destructive  ‘time  bomb’ 
programs  designed  to  shut  down  switching  hubs,  disrupted  E-91 1  services 
throughout  the  eastern  seaboard,  and  boasted  that  they  have  the  capability 
to  bring  down  all  switches  in  Manhattan.  [Bollentin,  1996,  pg.  20] 
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c.  Unicast  versus  Multicast  Message  Addresses 

Most  Internet  communications  rely  almost  exclusively  on  unicast  (i.e. 
point-to-point)  messages.  Messages  from  one  host  typically  are  addressed  and  sent  to 
only  one  other  host.  Even  multi-address  electronic  mail  messages  are  transmitted  as 
unicast  IP  datagrams  since  the  e-mail  message  is  replicated  at  the  mail  server  and  a  copy 
is  sent  to  each  addressee.  Internet  security  (and  hence  that  of  unicast  messages)  have 
been  discussed  throughout  this  thesis  and  is  documented  in  a  variety  of  sources  (Fraser, 

1996;  Klaus,  1995;  Ranum,  1995;  Curry,  1990). 

Despite  its  predominantly  unicast  nature,  the  Internet  also  supports 
multicast  (i.e.  multipoint-to-multipoint)  messages  using  the  Internet  Multicast  Backbone 
(MBone).  The  MBone  is  a  part  of  the  Internet  and  therefore  exhibits  the  same  vulnerabil¬ 
ities.  As  with  the  unicast  Internet,  security  is  provided  primarily  by  individual  MBone 
applications.  Most  of  these  applications  pose  little  threat  to  end  systems  as  they  cannot 
be  “coaxed”  into  writing  to  disk  by  incoming  packets  nor  do  they  run  set-uid?  However, 
MBone  management  tools  such  as  mtrace  or  mrinfo  do  run  set-uid  and  other  MBone 
management  tools  such  as  map-mbone  require  root  privileges.  (Kumar,  1996;  Savetz,  et 
al,  1996)  Giving  public  access  to  these  tools,  either  directly  or  via  a  script  imbedded  in  a 
home  page,  introduces  a  possible  system  vulnerability.  The  likelihood  an  automated 
script  can  be  used  to  invoke  these  tools  fast  enough  to  disrupt  network  service  or  that 

®  set-uid  is  a  flag  used  in  remote  procedure  calls  that  when  set  for  the  called  procedure, 
changes  the  calling  process’  uid  to  that  of  the  called  procedure.  If  the  called  procedure  is  running 
as  root,  then  the  calling  process  will  also  run  as  root  with  all  the  associated  privileges  until  the 
called  procedure  returns  (Curry,  1990). 
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these  applications  can  be  subverted  by  an  intruder  to  gain  access  to  system  files  is 
uncertain  but  the  vulnerability  exists  nonetheless.  A  recent  software  analysis  of  these 
monitoring  applications  indicates  that  they  are  adequately  secure  for  open  use  (Erdogan, 
,1996). 

The  MBone  is  also  theoretically  vulnerable  to  Trojan  Horses  disguised  as 
MBone  applications.  For  example,  someone  might  advertise  that  a  new  interactive 
whiteboard  (wb)  application  which  fixes  bugs  in  previous  versions  is  available  for 
download  from  the  Internet.  This  seems  to  be  a  useful  application  and  one  in  which 
people  might  be  interested.  Imagine  the  frustration  if  embedded  within  this  appealing 
application  was  the  command  rm  -rf  When  such  a  new  interactive  “whiteboard  applica¬ 
tion”  is  executed  all  files  below  the  current  directory  will  be  quietly  ereised.  Currently  the 
Trojan  Horse  threat  is  of  little  concern  as  there  are  relatively  few  MBone  applications. 
These  applications  are  written  by  a  relatively  small  number  of  individuals  who  are  trusted 
and  closely  monitored  within  the  MBone  commimity.  This  is  an  example  of  consensual 
administrative  policies  providing  group  security.  But  as  MBone  use  increases  and  the 
multicasting  influence  expands,  the  variety  and  number  of  MBone  applications  is  likely  to 
increase  thus  increasing  the  threat. 

The  MBone  is  also  vulnerable  to  threats  relating  to  security  firewall 
configurations.  The  first  vulnerability  is  the  susceptibility  to  multicast  address  spoofing. 
Multicast  messages  are  sent  over  the  regular  Internet  but  require  special  routers  to  handle 
the  multicast  addresses.  As  multicast  routers  are  not  widespread,  multicast  packets  are 
encapsulated  within  standard  unicast  packets.  Tunnels  are  established  between  multicast 
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routers  through  the  mesh  of  regular  unicast  routers.  The  vulnerability  exits  not  so  much 
in  the  MBone  itself,  as  in  network  security  firewalls.  Most  security  firewalls  examine 
host  IP  addresses  (in  this  case  the  mrouter  addresses  at  the  tunnel  endpoints)  accepting 
packets  from  authorized  hosts  and  rejecting  packets  from  unauthorized  hosts.  However, 
packets  traversing  the  multicast  tunnel  are  not  authenticated,  and  therefore  any  IP  host 
can  send  malicious  packets  through  the  firewall  by  posing  as  the  remote  tunnel  endpoint. 
(Kumar,  1996) 

Directly  related  to  the  previous  vulnerability  is  the  fact  that  current  MBone 
applications  use  only  the  User  Datagram  Protocol  (UDP)  at  the  transport  layer,  but 
multicast  addresses  are  at  the  IP  layer.  Because  most  firewalls  filter  on  the  host  IP 
address  (e.g.  the  IP  address  of  the  mrouter  serving  as  the  remote  tunnel  endpoint),  all 
UDP  packets  on  subscribed  multicast  channel/port  combinations  are  received  by  the 
operating  system  kernel  regardless  of  the  UDP  packet  contents.  Users  may  think  they  are 
receiving  audio  packets  when  in  actuality  they  are  receiving  a  malicious  network  file 
system  packet.  To  protect  against  such  an  attack,  filtering  routers  must  inspect  the  UDP 
payload  of  incoming  IP  packets  for  any  unwanted  UDP  ports  or  protocols.  Trusted 
software  must  also  behave  robustly  in  the  presence  of  unexpected  inputs.  (Savetz  et  al, 
1996) 

As  with  all  network  security  decisions,  security  for  the  MBone  is  a 
tradeoff.  MBone  applications  can  be  reasonably  trusted  at  present  because  most  applica¬ 
tions  are  written  by  “trusted”  individuals.  This  may  change  as  multicasting  becomes 
more  widespread.  Multicast  packets  can  also  be  filtered  by  firewalls  for  added  security. 
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However,  a  balance  is  required  between  the  two  filtering  extremes.  Filtering  granularity 
that  is  too  fine  will  degrade  performance  and  may  unnecessarily  restrict  access  to  MBone 
services.  Filtering  granularity  that  is  too  coarse  may  leave  the  internal  LAN  vulnerable 
to  attack.  To  date,  malevolent  security  incidents  on  the  MBone  have  been  rare  or 
nonexistent. 

Other  threats  associated  with  the  MBone  also  have  been  identified,  most 
affecting  system  availability  or  the  quality  of  service  (QoS).  For  example,  one  user 
leaving  a  microphone  on  or  transmitting  high-bandvvidth  video  can  temporarily  degrade 
network  services  for  every  other  user  (Macedonia  and  Brutzman,  1994).  Setting  the 
time-to-live  variable  too  high  may  also  flood  the  MBone  and  make  it  unusable.  As  with 
any  other  secure  channel,  trusted  distribution  of  cryptographic  keys  for  “private”  MBone 
sessions  also  remains  a  separate  issue.  In  general,  administrative  policies  (such  as 
Internet  Service  Providers  detecting/isolating  offenders  and  community  cooperation)  have 
been  remarkably  effective  in  minimizing  system  availability  and  QoS  problems.  Lessons 
learned  are  typically  automated  and  incorporated  into  global  software  distributions. 

F.  IMPLEMENTATION  ISSUES 

1.  Effectiveness  and  Efficiency 

Because  AIS  security  competes  for  scarce  organizational  resources  (i.e.  labor 
hours  and  capital),  the  resources  that  are  allocated  to  AIS  security  must  be  justified. 
Controls  must  be  both  effective  and  efficient.  A  control  that  does  not  adequately  protect 
against  the  threat  for  which  it  was  implemented  is  not  effective.  A  control  that  protects 
against  the  threat  but  is  too  costly  to  implement,  operate  or  maintain  (compared  to  the 
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value  of  the  hardware,  software  and  data  it  is  protecting)  is  inefficient.  Managers  must 
carefully  consider  the  cost/benefit  relationship  between  AIS  security  controls  and  the 
value  of  the  information  and  equipment  the  controls  are  protecting  given  the  existing 
environment.  NFS  policies  regarding  effectiveness  and  efficiency  are  currently  decided 
on  a  LAN  by  LAN  (typically  department  by  department)  basis. 

2.  Life-Cycle  Costs 

To  adequately  justify  security  controls,  management  must  understand  the  costs 
associated  with  AIS  security.  AIS  security  increases  the  cost  of  an  information  system 
over  the  entire  lifespan  of  the  system.  Costs  are  incurred  to  implement  controls.  Costs 
are  incurred  to  operate,  maintain,  support,  monitor  and  enforce  the  security  policy  and  the 
controls  that  are  implemented.  All  controls  interfere  with  productivity  in  one  fashion  or 
another  and  thereby  also  increase  system  costs  —  hence  the  less  obtrusive  the  controls, 
the  lower  the  cost  incurred.  Finally,  AIS  security  controls  reduce  a  system’s  life  span  by 
increasing  a  system’s  complexity  and  reducing  its  flexibility  —  the  more  complex  and 
less  flexible  a  system,  the  sooner  the  system  will  need  to  be  replaced.  This  requires  the 
organization  to  expend  resources  sooner  than  it  otherwise  might.  (Baskerville,  1988) 

NFS  life-cycle  planning  is  performed  on  a  component  by  component  basis.  NFS 
life-cycle  planning  requirements  are  briefly  described  in  (NFS,  1992). 

3.  Convenience  and  Acceptance 

Managers  do  not  exist  in  a  vacuiun;  other  stakeholders  —  administrators,  techni¬ 
cians  and  users  —  are  affected  by  their  decisions.  This  often  complicates  the  AIS 
security  problem  due  to  occasional  lack  of  consensus  among  the  various  system 
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stakeholders  on  just  how  vulnerable  the  system  is  and  what  needs  to  be  done  about  it.  It 
does  not  much  matter  what  security  controls  are  implemented  if  such  controls  unduly 
inconvenience  persoimel.  Security  controls  that  are  excessively  complex  or  restrictive 
will  soon  be  circumvented  by  IS  personnel  and  users  thereby  rendering  such  controls 
useless  (Fitzgerald,  1993).  Extended  system  shutdowns  for  security  repairs  (as  in  the 
December  1995  NFS  incident)  jeopardizes  daily  operations,  mission  completion  and 
long-term  sustainability. 

Ideally,  security  controls  are  designed  into  a  system  from  its  inception,  taking  user 
and  mission  needs  into  account.  This  practice  tends  to  reduce  the  productivity  costs 
associated  with  AIS  security  by  making  control  and  audit  mechanisms  transparent  to 
system  users  and  reducing  user  resistance  to  such  mechanisms.  However,  security 
requirements  are  often  overlooked  during  the  requirements-analysis  phase  of  system 
design.  (Fraser,  1996;  NCSC,  1993;  Baskerville,  1989;  Palmer  and  Potter,  1989) 
Similarly,  if  IS  administrators,  technicians  and  users  do  not  understand  the  need  for 
system  security,  any  control  that  is  implemented  will  likely  be  circumvented.  It  is 
therefore  paramount  that  IS  personnel  be  made  aware  of  IS  security  needs  and  priorities 
through  training  and  eontinued  communication  between  and  among  managers, 
administrators,  and  users.  (Fitzgerald,  1993;  Wong  and  Watt,  1990) 

G.  SUMMARY 

Securing  a  networked  computer  system  is  a  complex  problem.  If  a  networked 
computer  system  is  to  be  secure,  managers  must  understand  the  need  for  system  security 
and  decide  how  much  and  what  type  of  security  controls  are  required.  Their  decisions 
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and  priorities  must  be  well  documented  and  widely  distributed  in  the  form  of  an  organiza¬ 
tional  security  policy.  The  security  policy  must  clearly  state  the  rules  and  goals  that  the 
system  security  controls  will  enforce.  Managers  need  to  ensure  adequate  resources  are 
allocated  to  effectively  implement,  monitor  and  enforce  the  security  policy. 

Managers  need  to  understand  the  environment  in  which  their  organization's 
computer  system/network  is  operating  and  the  threats  which  the  environment  presents. 

By  understanding  the  enemy,  so  to  speak,  managers  can  develop  and  implement  controls, 
plans  and  procedures  to  either  prevent  a  security  incident  from  occurring  or  to  effectively 
deal  with  it  if  one  actually  occurs.  By  being  proactive  rather  than  reactive,  the  organiza¬ 
tion  may  be  able  to  recover  from  an  incident  much  more  quickly  and  at  far  less  cost  than 
it  otherwise  might. 

The  foundation  of  networked  computer  system  security  is  in  controlling  both 
physical  and  telecommunications  access  to  the  system.  Telecommunication  access 
control  is  accomplished  through  identification,  authentication  and  authorization  mecha¬ 
nisms  supported  by  cryptographic  software.  Access  control  becomes  more  complex  when 
access  is  allowed  over  both  the  Internet  and  direct-dial  telephone  lines.  Nonrepudiation, 
data  integrity  and  data  confidentiality  are  becoming  more  important  as  organizations 
begin  to  use  networking  and  the  Internet  for  commercial  gain.  Nonrepudiation,  data 
confidentiality  and  data  integrity  also  can  be  accomplished  with  digital  signatures  and 
cryptographic  algorithms.  Finally,  while  not  necessarily  unique,  multicasting  does 
include  certain  vulnerabilities  that  have  been  successfully  prevented  to  date  through 
trusted  software  and  effective  administrative  policies. 
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Security  controls  must  be  carefully  selected  based  on  their  effectiveness,  ease  of 
use  and  efficiency.  Complex  controls  that  prove  too  restrictive  or  difficult  to  use  will 
simply  be  circumvented  by  exasperated  users  and  administrators.  Of  course,  all  system 
users  must  be  made  aware  of  and  understand  the  need  for  AIS  security.  Increased 
awareness  and  understanding  can  be  achieved  through  training  and  frequent  communica¬ 
tion  between  and  among  managers,  AIS  personnel  and  users.  Time  and  resources  spent 
on  training  can  pay  dividends  by  increasing  the  likelihood  that  security  controls  are 
imderstood  and  followed. 
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V.  SOFTWARE  INSTALLATION:  KERBEROS 


A.  INTRODUCTION 

Section  B  in  this  chapter  explains  the  motivation  for  implementing  the  Kerberos 
authentication  and  authorization  protocol.  Section  C  presents  a  general  discussion  of  the 
Kerberos  protocol  and  how  it  works.  A  detailed  analysis  is  not  presented  here  as  more  in- 
depth  discussions  of  the  protocol  can  be  found  in  (Kohl  et  al,  1992),  (Steiner  et  al,  1988) 
and  (Miller  et  al,  1987).  Section  D  discusses  some  of  the  planning  issues  that  must  be 
considered  before  any  meaningful  implementation  of  Kerberos  is  undertaken. 

B.  MOTIVATION:  PASSWORD-SNIFFING  PROTECTION 

One  of  the  most  common  attacks  against  network  security  is  a  packet-sniffing  or 
eavesdropping  attack  during  remote  sessions.  With  standard  Unix  remote  access 
applications  (e.g.  rlogin,  rsh,  rep,  ftp,  telnet  etc.),  passwords  are  transmitted  from  the 
remote  system  to  the  host  system  over  the  network  in  the  clear  (i.e.  unencrypted).  An 
eavesdropper  at  any  intermediate  node  between  the  remote  system  and  the  host  can  easily 
capture  the  login  sequence  (of  user  ID  and  password).  The  captured  sequence  can  then  be 
used  for  future  unauthorized  access  to  the  host  system  —  a  particularly  undesirable 
consequence  of  remote  computing.  This  type  of  attack  has  been  rather  successful  in  the 
past.  For  example,  in  February  1994,  the  Computer  Emergency  Response  Team  (CERT) 
at  the  Software  Engineering  Institute  (SEI)  at  Carnegie  Mellon  University  issued  an 
advisory  for  all  Internet  users  to  change  their  passwords  in  the  wake  of  numerous 
successful  packet-sniffing  attacks  (CERT,  1994). 
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Academic  users  often  need  to  travel  to  conferences  and  maintain  Internet  cormec- 


tivity  to  securely  collaborate  over  the  Internet  with  colleagues  at  remote  locations.  Thus 
password  security  is  an  important  requirement.  One  solution  to  the  problem  of  transmit¬ 
ting  passwords  over  an  insecure  network  is  the  Kerberos  authentication  and  authorization 
protocol. 

C.  THE  KERBEROS  PROTOCOL 

This  section  briefly  explains  the  Kerberos  protocol.  Subsection  1  provides  a  short 
description  of  Kerberos  and  provides  some  background  information  with  regard  to  the 
protocol’s  history  and  development.  Subsection  2  provides  a  general  overview  of  how 
the  authentication  protocol  works. 

1.  Background 

Kerberos  is  a  client/server-based  access  security  protocol  that  relies  on  a  trusted 
host  known  as  the  "Kerberos  authentication  server,"  the  "Kerberos  key  distribution  center 
(KDC),"  or  simply  "Kerberos."  Kerberos  provides  authentication  services  for  network 
principals  that  are  acceptable  to  both  the  client  and  the  server.  A  network  principal  is  any 
user  (or  a  client  process  acting  on  behalf  of  a  user)  or  service  on  a  network.  The  trusted 
host  (i.e.  “Kerberos”  host  or  simply  the  “KDC”)  stores  a  secret  password  for  all  principals 
on  the  network.  Any  principal  wishing  to  access  the  network  or  a  protected  network 
service  must  first  authenticate  itself  to  the  KDC  before  access  is  granted. 

Kerberos  was  developed  in  1 987  by  researchers  at  the  Massachusetts  Institute  of 
Technology  (MIT)  to  protect  emerging  network  services  provided  by  the  school's  Project 
Athena.  When  Kerberos  was  designed,  MIT  was  operating  750  computers  on  30  subnets 
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and  supporting  over  5000  active  users.  MIT's  computing  environment  consisted  of  both 
distributed  untrusted  workstations  and  time-share  mainframe-based  systems,  but  there 
was  virtually  no  centralized  control  of  the  computing  resources  on  the  MIT  campus  and 
the  individual  workstations  were  unsecured.  Malicious  users  might  subvert  or  otherwise 
gain  control  of  individual  workstation  operating  systems  and  gain  unauthorized  access  to 
the  network  or  masquerade  as  another  user  to  gain  unauthorized  access  to  files.  (Miller  et 
al,  1987) 

The  primary  purpose  of  Kerberos  was  to  extend  the  familiar  time-sharing  notions 
of  authentication,  authorization  and  auditing  to  the  distributed  network  environment 
operating  with  untrusted  workstations.  To  that  end,  Kerberos  had  three  goals:  (1) 
provide  both  one-way  and  mutual  authentication  between  principals  to  the  granularity  of  a 
single  user  and  a  single  network  service  instance;  (2)  provide  coarse  access  authorization 
and  allow  services  to  implement  specific  authorization  models  as  required  while  assum¬ 
ing  reliable  authentication  of  users;  and  (3)  allow  integration  of  a  modular  accounting 
system  to  provide  accoimting  services  for  resources  as  required  (Miller  et  al,  1987). 

While  the  Kerberos  protocol  does  have  some  limitations  and  weaknesses,  the  protocol 
effectively  achieves  these  goals  (Bellovin  and  Merritt,  1990). 

2.  The  Kerberos  Protocol 
a.  Authentication 

Kerberos  is  a  client/server-based  protocol  that  relies  on  a  trusted  third 
party  to  provide  authentication  services  for  both  a  network  client  and  the  network  service 
the  client  wishes  to  access.  Thus  any  network  application  can  be  customized  to  comply 
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with  the  Kerberos  authentication  protocol.  The  Kerberos  protocol  does  not  transmit 
passwords  per  se  over  the  untrusted  network,  but  rather  authenticates  users  and  processes 
at  the  client  machine.  The  protocol  uses  a  modularized  64-bit  encryption  algorithm  to 
accomplish  the  authentication  function.  The  default  encryption  algorithm  is  the  Digital 
Encryption  Standard  (DES)  (NIST,  1988),  but  any  64-bit  encryption  algorithm  can  be 
used.  The  protocol  is  flexible  in  that  the  same  general  principle  is  used  both  for  the  initial 
network  login  sequence  and  for  subsequent  network  application  and  service  access. 

Figure  6  illustrates  the  general  authentication  protocol. 

When  initially  accessing  the  network  a  client  must  request  authentication 
from  the  centralized  Kerberos  key  distribution  center  (KDC)  (i.e.  Kerberos).  Integral  to 
the  KDC  is  a  database  that  stores  the  password  for  every  user  and  each  "kerberized" 
network  application  or  service.  Upon  verifying  the  ID  of  the  user,  the  KDC  issues  the 
client  an  initial  encrypted  authentication  ticket  called  a  “ticket-granting  ticket”  (TGT). 
This  ticket  is  encrypted  using  the  user's  stored  password  as  the  seed  for  the  encryption 
algorithm.  To  decrypt  the  TGT,  the  client  process  prompts  the  user  for  their  password. 
The  user  will  only  be  granted  access  to  the  network  if  they  enter  the  correct  password  to 
decrypt  the  TGT. 

At  this  point  the  user  is  only  logged  onto  the  network;  they  can  access 
standard  applications  or  services  but  they  cannot  yet  access  Kerberized  applications  or 
services.  To  make  the  protocol  as  transparent  to  the  user  as  possible,  the  protocol 
requires  the  user  to  enter  their  password  only  once  during  any  one  session.  The  password 
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Figure  6.  The  Kerberos  authentication  protocol.  After  (Steiner,  et  al,  1988) 


is  kept  in  memory  on  the  client  machine  only  long  enough  to  decrypt  the  TGT.  The  TGT 
is  then  used  in  lieu  of  a  password  to  obtain  authentication  tickets  for  individual  network 
applications  and  services  as  required  by  the  user. 

Once  logged  onto  the  network,  a  user  wishing  to  access  a  network 
application  or  service  must  obtain  an  authentication  ticket  from  a  ticket  granting  server 
(TGS)  by  submitting  an  authentication  request  and  the  TGT  to  the  TGS.  The  TGS  may  or 
may  not  reside  on  the  same  machine  as  the  KDC.  Once  obtained,  the  application  or 
service  ticket  is  then  presented  to  the  particular  application  server  to  gain  access  to  the 
application  or  service. 

The  structure  of  each  ticket  (i.e.  the  TGT  obtained  from  the  KDC  and  each 
specific  service  ticket  obtained  from  the  TGS)  is  identical  and  is  illustrated  in  Figure  7. 
Inside  each  ticket  is  a  session  key  for  use  between  the  client  and  the  server  portion  of  the 
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Figure  7.  Contents  of  a  Kerberos  authentication  ticket. 


network  application  or  service  (including  the  TGS  in  the  case  of  the  initial  TGT).  Each 
authentication  ticket  issued  to  a  client  process  also  contains  another  ticket  that  is  en¬ 
crypted  with  the  application's  (or  TGS’s)  password.  This  inner  ticket  is  not  readable  to 
the  client  (or  the  user  on  whose  behalf  the  client  is  operating);  it  may  only  be  decrypted 
by  the  server  portion  of  the  applicable  application  or  service. 

The  inner  ticket  has  its  own  structure  as  shown  in  Figure  8.  Inside  the 
inner  ticket  is  the  client's  name,  the  client's  IP  address,  the  server's  name,  the  current 
computer  time,  the  ticket’s  lifespan,  and  the  same  session  key  that  was  issued  to  the  client 
as  part  of  the  authentication  ticket,  whether  the  authentication  ticket  is  the  original  TGT 
or  is  a  specific  service  ticket. 

To  access  a  particular  "kerberized"  network  application  the  client  process 
will  prepare  an  authenticator  composed  of  the  client's  name,  IP  address  and  the  current 
time.  The  authenticator  is  encrypted  with  the  session  key  issued  with  the  initial  TGT. 

The  client  vwll  present  this  encrypted  authenticator,  the  name  of  the  specific  service  and 
the  encrypted  inner  ticket  (i.e.  the  actual  TGT)  to  the  ticket  granting  server  (TGS).  The 
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Figure  8.  Contents  of  the  encrypted  inner  ticket  within  a  Kerberos 


authentication  ticket. 

TGS  decrypts  the  encrypted  TGT  with  its  unique  “password”and  retrieves  the  session  key 
from  within  the  TGT.  The  TGT  then  decrypts  the  client's  authenticator  \vith  the  session 
key  and  compares  the  information  contained  in  the  TGT  to  that  contained  in  the 
authenticator.  If  the  client  name  and  IP  address  match,  and  the  time  stamp  on  the 
authenticator  is  not  beyond  the  lifespan  of  the  TGT,  the  TGS  authenticates  the  client  and 
issues  an  authentication  ticket  for  the  specific  application  service  specified  in  the  request. 
This  new  ticket  has  the  same  structure  as  the  original  TGT  but  a  different  session  key  for 
use  between  the  client  and  the  application  server. 

The  authentication  process  to  the  specific  application  server  is  identical  to 
that  which  has  just  been  described.  The  authenticator  and  the  encrypted  inner  ticket  are 
now  presented  to  the  specific  application  server. 

b.  Authorization 

Kerberos  provides  the  flexibility  to  allow  different  network  services  to 
implement  different  authorization  models  (access  control  lists  for  example).  There  are 
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three  ways  the  Kerberos  authentication  protocol  can  be  extended  to  include  authorization. 
The  first  is  by  including  authorization  information  for  each  network  service  directly  in  the 
Kerberos  database.  Only  authorized  users  are  then  granted  specific  service  tickets.  The 
second  means  of  providing  authorization  is  for  the  system  to  maintain  separate  access 
control  lists  (ACLs)  for  each  service.  The  Kerberos  protocol  can  be  modified  to  provide 
certified  copies  of  the  ACL  in  place  of  an  authentication  ticket.  The  certified  ACL  is  then 
presented  to  the  ultimate  service  in  lieu  of  the  authentication  ticket.  The  third  way  the 
Kerberos  protocol  can  be  modified  to  provide  authorization  is  by  customizing  each 
individual  service  to  maintain  its  own  authorization  information.  The  third  authorization 
method  is  recommended  by  the  Kerberos  developers  at  MIT.  Library  modules 
implementing  this  authorization  model  using  ACLs  are  included  in  the  standard  MIT 
distribution  of  Kerberos.  (Miller  e/ a/.,  1987) 

While  the  Kerberos  authentication  model  is  centralized,  the  authorization 
model  is  decentralized.  The  principle  idea  behind  decentralized  authorization  is  that  each 
service  is  likely  to  know  best  who  the  authorized  users  are  and  how  to  best  implement 
that  authorization.  The  advantages  of  this  model  are  outlined  in  (Miller  et  al,  1987)  and 
will  not  be  addressed  here. 

c.  Accounting 

Kerberos  does  not  implement  an  accounting  system  itself,  but  it  can 
accommodate  a  modular  accounting  system  to  track  resource  usage  (Miller  et  al,  1987). 
The  modularized  accounting  system  is  used  for  tracking  system  resource  usage.  That 
information  is  usually  used  for  an  organization’s  charge-back/computer  resource  billing 
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policy.  If  a  network  application  (e.g.  the  print  daemon)  is  “kerberized”  and  the 
organization  implements  a  charge-back  policy,  then  Kerberos  can  accommodate  a 
modularized  accoimting  system  to  gather  the  necessary  data. 

For  discussion’s  sake,  it  does  not  seem  feasible  to  use  a  modularized 
accounting  system  to  evaluate  usage  and  practicality  of  the  Kerberos  system  itself  as 
Kerberos  does  only  one  thing:  control  access  to  system  resources.  Kerberos  accom¬ 
plishes  this  function  through  authentication  and  authorization.  The  Kerberos  system  itself 
is  Boolean  in  nature;  either  you  use  it  or  you  do  not;  either  a  network  application  is 
“Kerberized”  or  it  is  not.  If  an  organization  implements  Kerberos  to  protect  network 
resources,  then  by  default  Kerberos  gets  used. 

Evaluating  the  practicality  of  Kerberos  is  equally  problematic.  As  with 
most  computer  system/network  security  mechanisms,  evaluating  the  practicality  of 
Kerberos  is  similar  to  precisely  evaluating  the  practicality  of  life  insurance.  How  does 
one  do  that?  The  nice  thing  about  Kerberos  is  that  it  can  replace  the  standard  login 
sequence  and  be  transparent  to  the  user.  Therefore  it  is  only  as  obtrusive  as  the  regular 
login  sequence.  This  is  assuming  of  course  that  network  managers  and  system  adminis¬ 
trators  want  to  implement  Kerberos  and  take  advantage  of  the  access  protection  it 
provides. 

D.  PLANNING  REQUIREMENTS 

Specific  planning  requirements  will  vary  from  organization  to  organization.  This 
section  simply  highlights  some  of  the  issues  that  must  be  addressed  before  implementing 
Kerberos  within  an  organization.  Subsection  1  addresses  network  organization  issues. 
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Subsection  2  discusses  network  service  issues.  Subsection  3  addresses  network  admin¬ 
istration  issues. 

1.  Network  Organization  and  Realms 

Any  large-scale  implementation  of  Kerberos  (such  as  those  at  MIT  (Miller,  et  al, 
1987))  requires  considerable  planning.  Kerberos  operates  within  the  concept  of  a.  realm 
which  is  similar  to  an  Internet  domain.  However  a  realm  is  fundamentally  different  from 
an  Internet  domain.  A  domain  is  based  on  a  common  set  of  network  addresses  that  can  be 
divided  easily  into  subdomains  by  simply  parsing  up  the  common  set  of  addresses  into 
subsets  which  can  be  allocated  to  form  subnetworks.  On  the  other  hand,  a  realm  is  an 
independent  administrative  division  or  grouping  of  computers  that  cannot  be  divided  into 
“subrealms.”  As  an  application  layer  protocol,  Kerberos  uses  lower  level  protocols  only 
for  transmission  and  delivery.  A  host’s  network  address  is  not  a  prerequisite  for  inclusion 
in  a  particular  realm.  (Miller,  et  al,  1987;  Neuman  and  Steiner,  1988) 

Network  administrators  deploying  Kerberos  must  decide  how  many  realms  they 
are  going  to  operate  at  their  site  and  how  these  realms  will  be  organized.  To  simplify 
network  management  it  is  recommended  that  realms  mirror  an  organization’s  top-level 
Internet  domain  name,  however  this  may  be  impractical  or  inefficient.  (Neuman  and 
Steiner,  1988).  Small  sites  can  operate  adequately  within  a  single  realm;  larger  sites  will 
require  multiple  realms.  For  example,  MIT  operates  with  three  realms  supporting  more 
than  5,000  users  and  750  computers  on  30  subnets  (Neuman  and  Steiner,  1988).  These 
decision  outcomes  will  depend  largely  on  the  size  of  the  site  and  the  number  of  users  at 
the  site. 
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2. 


Network  Services 


Managers  must  also  decide  how  many  application  servers  will  be  installed  within 
each  realm,  where  those  application  servers  will  be  located  both  physically  and  logically 
at  the  site,  and  what  network  applications/services  will  be  protected.  This  section 
discusses  these  decision  issues. 

a.  Application  Servers 

(Eichin  and  McGregor,  1995)  recommends  making  every  local  host  an 
application  server  so  users  can  access  them  directly.  While  this  may  be  desirable,  it  may 
be  impractical  for  large  sites.  Because  a  single  master  KDC  has  complete  authentication 
and  administration  authority  'within  a  particular  realm,  making  every  local  host  an 
application  server  at  a  large  single-realm  site  will  greatly  increase  the  workload  on  the 
single  master  KDC.  This  will  also  increase  the  size  of  the  KDC’s  database  and  make 
database  management  more  difficult. 

The  server  workload  issue  can  be  solved  by  implementing  slave  servers 
that  contain  a  read-only  copy  of  the  database,  but  the  database  management  issue  remains. 
Both  the  server  workload  and  database  management  issues  can  be  solved  by  subdividing 
a  large  realm  into  a  collection  of  smaller  realms.  In  this  case  authentication  between 
realms  is  desirable  but  is  not  fully  supported  by  the  current  version  of  Kerberos  (version 
4)  (Miller,  et  al,  1987).  Cross-realm  authentication  is  supported  with  version  5,  but 
version  5  is  still  in  the  beta  testing  phase  with  many  bugs  left  to  iron  out  (Kohl  and 
Neuman,  1993). 
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The  decision  concerning  which  applications  and  services  to  protect  using 
Kerberos  is  closely  related  to  the  earlier  decision  concerning  which  hosts  will  be 
application  servers.  It  may  be  desirable  to  have  every  network  host  provide  some  basic 
set  of  “kerberized”  services  (e.g.  rlogin,  telnet,  rsh,  rep,  ftp  etc.),  but  it  is  also  reasonable 
to  limit  some  applications  (e.g.  printer  daemons  and  World  Wide  Web  servers)  to  a  few 
specific  machines.  Freeware  distributions  of  Kerberos  include  “kerberized”  versions  of 
the  standard  Unix  r-commands  (i.e.  rlogin,  rep  and  rshell)  and  most  freeware  distribu¬ 
tions  also  include  “kerberized”  telnet,  tftp,ftp  and  pop  (e-mail  server)  applications. 
Freeware  distributions  of  Kerberos  also  include  a  library  of  procedures  and  subroutines 
programmers  can  use  to  “kerberize”  existing  applications.  The  time  and  expense  of 
converting  applications  will  depend  on  programmer  skill  and  the  complexity  and  size  of 
the  applications  managers  wish  to  “kerberize”  and  make  available  to  users.  This  remains 
an  area  for  further  research  since  thesis  does  not  address  specific  costs. 

Another  closely  related  issue  concerns  where  within  an  organization 
application  servers  will  be  placed  (both  physically  and  logically  with  respect  to  network 
addressing).  This  point  is  moot  for  those  sites  that  make  every  host  an  application  server 
for  every  application.  Since  in  most  sites  it  is  unlikely  every  host  will  support  every 
application,  this  issue  must  also  be  addressed. 

b.  Clients 

Every  network  host  (including  the  application  servers)  for  a  legitimate 
implementation  of  Kerberos  will  be  a  Kerberos  client.  The  decision  to  limit  the 
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accessibility  of  other  “kerberized”  applications  to  specific  hosts  is  no  different  than  under 
standard  non-Kerberos  practices. 

3.  Network  Administration 

Network  administration  when  operating  with  Kerberos  is  only  slightly  more 
complex  than  when  operating  without  Kerberos.  The  added  complexity  results  from 
having  to  manage  an  additional  database  containing  passwords  for  both  network  users 
and  for  the  network  services.  However,  depending  on  an  organization’s  security  policy, 
the  standard  passwords  can  be  disabled  thereby  eliminating  the  need  to  separately  manage 
standard  passwords.  The  motivation  here  is  to  make  the  Kerberos  initialization  process 
transparent  to  the  user  by  replacing  the  standard  login  script  with  one  that  handles  the 
Kerberos  initialization.  When  a  user  logs  into  a  workstation  they  are  automatieally 
initialized  to  the  KDC  for  that  realm.  All  authentication  requirements  within  that  realm 
will  then  be  handled  by  Kerberos.  From  a  user’s  standpoint  the  whole  process  is 
invisible.  In  either  case  user  accounts  must  be  managed,  users  and  network  administra¬ 
tors  alike  must  be  trained,  network  services  must  be  managed,  network  access  must  be 
monitored,  etc.  A  well-planned  implementation  can  eliminate  many  administrative 
burdens. 

E.  SUMMARY 

The  Kerberos  protocol  provides  authentication  of  users  and  client  processes  by 
means  of  authentication  tickets.  The  protocol  also  supports  authorization  and  can 
accommodate  modular  aecounting  systems  to  traek  system  usage.  This  chapter  explains 
the  motivation  for  implementing  the  Kerberos  protocol  and  briefly  describes  how  the 
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protocol  works.  This  chapter  also  discusses  many  of  the  planning  issues  that  must  be 
addressed  prior  to  an  operational  implementation  of  Kerberos.  Kerberos  is  of  interest  to 
NFS  as  a  means  to  provide  remote  password  protection  to  seamlessly  and  securely  extend 
LAN  connectivity  across  the  Internet. 
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VI.  INTEGRATED  IP/ATM  LANAVAN  SITE  SECURITY  SURVEY 


A.  INTRODUCTION 

The  IP/ATM  LANAVAN  is  located  in  the  System  Technology  Lab  (STL)  at  NPS. 
The  STL  contains  both  classified  and  unclassified  computer  networks/systems,  but  this 
thesis  addresses  only  the  unclassified  systems.  For  simplicity,  the  abbreviation  STL  is 
used  throughout  this  chapter  to  designate  the  unclassified  system.  This  chapter  docu¬ 
ments  the  results  of  a  site  security  survey  conducted  for  the  unclassified  STL  IP/ATM 
LAN/WAN.  This  chapter  is  not  a  risk  analysis  per  se,  but  merely  a  careful  look  at  the 
level  of  security  for  the  unclassified  networked  computer  system  as  well  as  what  work 
still  needs  to  be  done.  Conclusions  in  this  chapter  are  drawn  fi'om  a  comparison  of  the 
information  obtained  in  background  research,  structured  interviews  and  fi'ee-form 
interviews  with  the  STL  computing  staff  Issues  are  described  in  detail  in  Chapter  IV. 
Section  B  briefly  describes  and  illustrates  the  integrated  IP/ATM  LANAVAN  network 
topology.  Results  of  the  STL  site  security  survey  are  presented  in  section  C. 

B.  INTEGRATED  IP/ATM  LANAVAN  TOPOLOGY 

Figure  9  illustrates  the  topology  of  the  integrated  IP/ATM  LAN/WAN  at  NPS. 
(Courtney,  1996)  explains  this  topology  in  detail.  In  general,  the  core  of  the  network 
consists  of  two  Unix  workstations  connected  together  through  both  an  IP  Ethernet 
interface  and  an  ATM  interface.  On  the  left  side  of  Figure  9,  the  IP  Ethernet  interfaces 
connect  the  workstations  to  the  STL  subnet,  which  is  connected  to  the  campus  backbone 
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Figure  9.  IP/ ATM  LAN/WAN  topology.  From  (Courtney,  1996). 


and  then  to  the  Internet  through  the  campus  firewall.  On  the  right  side  of  Figure  9,  the 
ATM  interfaces  are  connected  to  a  Cisco  A- 100  ATM  switch  in  the  STL  which  is 
connected  to  another  A- 100  ATM  switch  located  in  the  campus  main  computer  center. 
From  the  computer  center  our  ATM  link  connects  directly  to  the  Monterey  BayNet 
regional  ATM  testbed. 

C.  SECURITY  ASSESSMENT 

The  observations  and  assessments  made  in  this  section  are  based  on  the  issues 
discussed  in  Chapter  IV.  Subsection  1  discusses  administration  issues.  Subsection  2 
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discusses  environmental  issues.  Subsection  3  discusses  software  and  data  issues. 
Subsection  4  discusses  telecommunication  and  system  access  issues.  Subsection  5 
discusses  implementation  issues.  Interviews  include  (Cochran,  1996),  (McGregor,  1996) 
and  (Williams,  1996). 

It  is  important  to  note  that  STL  administration,  operations  and  capabilities  are 
among  the  most  challenging  on  campus  (and  certainly  more  challenging  than  commercial 
organizations).  Staff  manning  is  less  than  desired,  also  a  common  occurrence  on  campus. 
This  and  other  anecdotal  evidence  leads  us  to  believe  that  STL  issues  are  representative 
of  conditions  throughout  NFS. 

1.  Administration  Issues 

a.  System  Availability  Requirements 
The  fundamental  mission  at  NFS  is  graduate  student  education  and 
research.  LAN/WAN  connectivity  and  the  availability  of  unclassified  computing 
resources  are  essential  to  that  mission,  yet  system  availability  requirements  for  the  STL 
resources  are  not  documented.  Assumptions  amongst  the  STL  computing  staff  are 
informal  but  consistent.  One  staff  member  stated  the  system  availability  requirement  was 
98%  (or  system  down  time  not  to  exceed  28  minutes  per  day),  while  another  was 
uncertain  but  stated  that  system  dotvn  time  was  not  to  exceed  10  minutes  a  day  which 
equates  to  a  99.99%  availability  requirement. 

System  availability  is  not  currently  tracked  or  explicitly  monitored. 
Because  students  or  faculty  are  quick  to  inform  staff  members  of  network  problems, 
monitoring  and  tracking  system  availability  is  considered  a  waste  of  manpower. 
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However,  monitoring  and  tracking  system  availability  not  only  serves  to  notify  system 
administrators  of  network  problems  but  also  to  document  the  performeince  and  effective¬ 
ness  of  various  controls.  Automated  network  monitoring  scripts  such  as  those  described 
in  (Edwards,  1996)  and  (Erdogan,  1996)  can  simplify  this  task  thereby  freeing  up  staff 
members  for  other  duties. 

Without  explicit  system  availability  requirements  and  accurate  system 
performance  monitoring,  there  is  no  tangible  means  to  evaluate  the  effectiveness  of 
networked  computer  system  security.  The  STL  staff  must  explicitly  define  and  document 
the  system  availability  requirements  for  the  unclassified  computing  resources.  Extending 
the  capabilities  of  the  (Edwards,  1996)  and  (Erdogan,  1996)  automatic  monitoring 
systems  to  include  system  availability  and  analysis  results  is  a  worthwhile  area  for  future 
work. 

b.  Security  and  Acceptable  Use  Policies  (A  UPs) 

Security  and  acceptable  use  policies  (AUPs)  for  NPS  in  general  are 
described  in  (NPS,  1992)  and  (NPS,  1995)  respectively.  No  additional  policies  are 
specified  for  the  STL. 

Limited  NPS  security  policies  are  posted  in  the  STL  but  are  not  enforced. 
For  example,  disallowing  food  and  drink  around  the  computer  equipment  may  be  a 
prudent  policy,  but  it  is  not  enforced  and  therefore  is  unheeded  by  STL  users  who 
apparently  do  not  see  the  utility  of  the  policy.  In  this  case  nonenforcement  correctly 
implies  irrelevance.  Nonenforcement  simply  reinforces  a  perception  that  the  NPS 
administration,  the  STL  computing  staff,  or  both,  have  a  myopic  view  of  the  scope  of 
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computer  security  or  do  not  understand  the  need  for  it  with  regards  to  unclassified 
systems. 

The  emphasis  here  is  not  so  much  on  the  enforcement  of  the  limited 
policies  but  on  their  enforceability,  adequacy  and  appropriateness.  Enforcement  ability  is 
not  so  much  having  staff  police  users  actions  (a  counterproductive  approach)  as  it  is 
having  policies  that  make  sense  to  users  as  common  practice.  Policies  are  not  static;  they 
must  reflect  the  nature,  culture  and  environment  of  the  organization.  Therefore  the  STL 
computing  staff  ought  to  critically  examine  the  existing  policies.  It  is  worthwhile  to 
identify  and  eliminate  policies  that  are  unimportant,  irrelevant  or  imenforceable.  It  is 
worthwhile  to  have  policies  which  are  truly  necessary  and  which  reflect  the  climate  and 
culture  of  the  organization  and  the  needs  of  all  stakeholders.  To  improve  acceptance  of 
the  policies,  users  must  be  involved  in  the  policy  process. 

c.  Contingency  Planning 

As  discussed  in  Chapter  IV,  contingency  planning  is  dependent  upon 
system  availability  requirements.  NPS  directives  state  that  a  "contingency  plan  will  be 
developed  for  each  AIS  where  a  disruption  of  services  would  have  a  critical  impact  on 
mission  accomplishment"  (NPS,  1992,  pg.  17).  Assuming  that  LAN/WAN  connectivity 
and  the  availability  of  unclassified  computing  resources  are  required  to  accomplish  the 
NPS  mission,  then  according  to  this  directive,  a  contingency  plan  is  required  for  all 
unclassified  systems. 

The  STL  staff  have  conducted  a  rudimentary  risk  analysis  and  developed 
limited  contingency  plans  for  their  classified  resources  but  have  not  done  so  for  their 
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unclassified  systems.  It  is  safe  to  assume  that  availability  of  the  unclassified  systems  is 
much  more  critical  than  that  of  the  classified  systems  as  the  unclassified  resources  are 
used  more  often  by  more  people.  Therefore  a  thorough  risk  analysis  and  contingency 
plan  needs  to  be  developed  for  the  unclassified  IP-based  resources  as  well.  ATM 
resources  are  experimental  and  not  mission  critical. 

d.  Roles  and  Responsibilities 

With  only  one  temporary  and  three  permanent  members,  the  STL  comput¬ 
ing  staff  is  seriously  undermanned  to  adequately  accomplish  necessary  security  functions 
in  addition  to  their  other  duties  and  responsibilities.  However,  the  STL  network  manager 
has  taken  steps  to  obtain  external  funding  and  increase  the  number  of  staff  members  to 
six  permanent  positions  plus  the  one  temporary  position  currently  filled.  If  approved  by 
NPS  administration,  this  will  greatly  improve  the  distribution  of  labor.  Assigning  one  of 
these  positions  the  primary  responsibility  of  network  security  will  also  help  improve  the 
security  posture  of  the  STL,  since  more  time  might  be  devoted  to  network  security.  To 
their  credit  however,  the  STL  computing  staff  (even  though  undermanned)  does  provide 
exceptional  support  to  the  faculty  and  students. 

2.  Environmental  Issues 

a.  Natural  Disasters 

The  only  environmental  threat  the  STL  staff  seems  even  remotely  con¬ 
cerned  about  is  excessive  heat  within  the  computer  room.  This  is  imderstandable  as  there 
already  have  been  some  heat-related  hardware  failures.  Steps  already  have  been  taken  to 
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fund,  procure  and  install  an  air  conditioning  system  in  the  STL  to  remedy  this  situation. 
The  system  is  expected  to  be  installed  by  the  end  of  the  year. 

While  excessive  heat  is  the  only  concern  of  the  STL  staff,  other  environ¬ 
mental  threats  certainly  exist.  The  threat  of  fire  is  always  present.  The  computer  room  is 
carpeted  presenting  the  threats  associated  with  static  electricity  and  dust.  Electrical 
power  is  not  necessarily  stable.  However,  few  controls  are  in  place  to  protect  against 
these  other  threats.  Automatic  heat  or  smoke  detectors  are  required  by  local  directive 
(NFS,  1 992)  but  are  not  present.  Automatic  sprinklers  are  not  installed  and  the  nearest 
fire  extinguisher  is  outside  the  computer  room  and  thirty  yards  down  the  passageway. 
Lfninterruptible  power  supplies  and  surge  protectors  are  not  installed. 

The  risks  associated  with  these  other  threats  may  already  have  been 
considered  but  nothing  has  been  documented.  Without  a  formal  risk  assessment  and 
documented  contingency  plan,  it  is  impossible  to  adequately  assess  the  importance  of  the 
other  threats  or  obtain  the  necessary  resources  to  adequately  protect  against  them.  As 
mentioned  above,  the  STL  staff  must  complete  a  formal  risk  assessment  and  develop  a 
contingency  plan  for  their  unclassified  systems.  It  is  possible  that  some  of  these  physical 
safeguards  might  be  fimded  by  campus  resources  rather  than  reimbursable  research. 

b.  Human  Disasters 

The  STL  computing  staff  considers  authorized  system  users  to  be  the 
greatest  threat  to  the  security  of  the  STL  systems.  Ordinarily  the  typical  user  is  a  student 
or  faculty  member  interested  only  in  their  relevant  application  programs.  They  give  little 
thought  to  issues  such  as  password  security.  Most  have  only  a  general  knowledge  of  file 
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permissions  and  how  to  effectively  use  them,  despite  the  requirement  for  annual  computer 
security  training  for  all  personnel.  The  annual  training  provided  by  the  NFS  administra¬ 
tion  (typically  a  short  briefing  lasting  less  than  30  minutes)  is  woefully  inadequate.  The 
STL  staff  cannot  rely  on  this  limited  training  but  must  take  the  necessary  steps  to  ensure 
users  are  adequately  trained. 

Physical  security  is  minimal.  Laboratory  spaces  are  protected  by  cipher 
lock  when  unmanned.  Inside  the  labs,  network  hardware  is  freely  accessible.  Network 
cabling  and  concentrators  are  not  physically  secure  and  hence  are  vulnerable  to  either 
deliberate  attack  or  accidental  disconnection  by  users  or  cleaning  personnel.  The  main 
network  file  servers  and  ATM  switches  are  also  freely  accessible.  While  it  is  under¬ 
standable  that  the  ATM  switches  are  accessible  due  to  ongoing  research  in  ATM  network 
technology,  it  is  unwise  to  allow  free  physical  access  to  the  main  network  file  server. 
Likewise,  the  Kerberos  key  distribution  center  for  the  STL  test  implementation  of  the 
Kerberos  authentication  and  authorization  system  is  freely  accessible  to  anyone.  This  is 
unsatisfactory  for  a  meaningful  implementation  of  Kerberos.  These  important  pieces  of 
the  network  architecture  need  to  be  physically  secure  inside  ordinarily  locked  rooms. 

3.  Software  and  Data  Issues 

a.  Configuration  Management 

The  STL  staff  tracks  system  software  configuration  reasonably  well,  but 
they  do  not  closely  track  application  software  installed  for  course  work  or  research 
projects.  There  is  no  mechanism  besides  notification  by  students  or  faculty  that  applica¬ 
tion  software  is  no  longer  needed.  Unneeded  application  software  not  only  takes  up  disk 
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space  that  may  be  required  for  other  programs  or  files,  but  it  may  also  interfere  with  the 
proper  configuration  of  newly  installed  software.  This  configuration  problem  will  always 
exist,  but  removing  unnecessary  applications  may  reduce  the  possibility  of  misconfig- 
uration  to  some  degree.  An  administrative  policy  and  an  adequate  number  of  administra¬ 
tors  are  needed. 

Another  vulnerability  exists  with  the  availability  of  CGI  and  perl  scripts 
on  home  pages.  CGI  and  perl  scripts  may  leak  information  about  the  host  system 
configuration  that  hackers  can  exploit.  The  simple  fact  that  a  script’s  source  is  readable 
simply  by  selecting  the  “View  Source”  option  on  the  browser  allows  an  intruder  the 
opportunity  to  study  a  script  and  search  for  ways  it  can  be  exploited.  Additionally,  scripts 
can  inadvertently  pass  remote  user  input  that  contains  shell  metacharacters  to  system 
procedure  calls  such  as  evalQ,  execO,popenO,  systertiQ.  The  point  here  is  not  that  these 
system  procedure  calls  should  not  be  use  but  that  script  writers  need  to  sanitize  user  input 
for  proper  form  and  content  before  passing  the  input  to  the  shell  for  execution.  With 
execQ  and  systemQ,  script  writers  can  also  execute  external  programs  by  sending  external 
data  directly  to  the  program  rather  than  going  through  a  shell.  (Stein,  1996)  provides  an 
excellent  discussion  of  the  vulnerabilities  associated  with  CGI  and  perl  scripts.  (Stein, 
1996) 

Security  of  CGI  and  jper/  scripts  is  only  as  good  as  the  design  and  testing 
of  the  scripts.  The  STL  staff  has  implemented  adequate  procedures  to  keep  scripts  in¬ 
accessible  to  external  hosts  until  they  have  been  tested  for  security.  CGI  and  perl  scripts 
are  tested  and  validated  on  an  isolated  internal  server  before  being  made  available  on  the 
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STL  web  server  accessible  by  Internet  users.  This  practice  ensures  an  acceptable  level  of 
security  within  the  STL. 

b.  Integrity  and  Confidentiality 

Confidentiality  and  integrity  of  most  system  software  and  data  are  not 
major  concerns  for  unclassified  systems.  Integrity  and  confidentiality  are  maintained 
primarily  by  controlling  access  to  the  network  (discussed  below). 

c.  System  Backups 

System  backups  are  woefully  inadequate  in  STL.  Full  system  backups  are 
done  only  quarterly;  incremental  backups  are  attempted  weekly.  Even  when  full  system 
backups  are  conducted  only  system  software  is  backed  up,  user  data  files  are  not.  The 
attitude  and  policy  of  the  STL  staff  is  that  users  must  backup  their  own  data  files.  This  is 
certainly  prudent  advice  and  users  should  attempt  to  do  so  to  as  great  an  extent  as 
possible,  but  user  backups  are  infeasible  for  large  files.  When  questioned  about  this 
policy  the  STL  network  manager  stated  that  users  need  only  inform  the  STL  staff  and 
appropriate  disk  space  on  a  mirrored  drive  will  be  provided,  yet  users  routinely  are  not 
aware  of  this.  This  demonstrates  an  additional  need  for  a  user  indoctrination  and  training 
program  for  the  STL. 

Two  recent  hard  disk  failures  have  further  demonstrated  the  need  for  more 
frequent  and  reliable  backups.  In  one  case  the  failure  resulted  in  lost  research  documenta¬ 
tion  that  had  been  stored  in  group  accounts.  To  little  avail,  one  STL  system  administrator 
spent  the  better  part  of  a  week  trying  to  recover  the  lost  files.  Many  of  the  lost  files  were 
written  by  users  who  have  long  since  departed  and  backups  were  not  available.  It  is 
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unreasonable  to  request  faculty  members  keep  backup  copies  of  all  ongoing  or  completed 
research  documentation  on  floppy  disks.  The  second  case  was  only  a  partial  failure 
affecting  application  files.  The  files  that  were  affected  were  able  to  be  moved  to  another 
portion  of  the  disk  before  any  files  were  permanently  lost.  However,  proper  reconfigura¬ 
tion  of  the  files  has  not  been  guaranteed. 

The  STL  staff  need  to  improve  their  backup  policy.  Given  the  nature  of 
today’s  technology,  system  users  reasonably  expect  adequate  backups  of  all  files  includ¬ 
ing  user  data  files.  Current  backup  practices  within  the  STL  do  not  sufficiently  assure  the 
availability  of  computing  resources  and  services.  There  are  plans  to  implement  an 
automated  tape  backup  system  with  future  upgrades  to  optical  disks.  This  is  a  step  in  the 
right  direction. 

4.  Telecommunications  and  System  Access  Issues 
a.  Access  Control 

Open  computing  and  maintaining  system  availability  are  both  essential  for 
the  STL.  Access  security  in  the  STL  is  good  but  the  network  is  still  vulnerable.  While  the 
current  Internet  connection  must  pass  through  the  campus  firewall,  the  ATM  connection 
does  not.  This  recognized  risk  is  currently  acceptable  because  only  permanent  virtual 
circuits  (PVCs)  are  configured  and  the  risk  is  minimal.  However,  as  experience  with 
ATM  expands  and  the  use  of  switched  virtual  circuits  (SVCs)  become  common,  this 
practice  will  become  unacceptable  since  the  ATM  call  setup  procedure  may  be  vulnerable 
to  password  compromise  or  other  threats  just  as  with  standard  Internet  connections.  If 
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plans  to  move  forward  with  ATM  are  implemented,  the  STL  staff  must  examine  and  plan 
ATM  security  now  rather  than  as  an  afterthought. 

Internal  campus  network  security  has  also  improved  considerably  since  the 
December  1995  security  incident.  TCP_wrapper'°  is  used  on  all  campus  traffic  and 
passwords  are  required  for  remote  login  and  telnet  sessions  between  campus  subnets.  If  a 
sniffing  program  is  somehow  installed  inside  the  firewall,  the  network  is  still  vulnerable 
to  common  password-sniffing  attacks.  Although  not  a  requirement,  sniffer  program 
detection  for  all  NFS  LANs  is  performed  periodically.  However,  passwords  are  still  sent 
across  the  network  in  the  clear  for  all  remote  login  sessions.  This  is  discussed  in  the  next 
section. 

b.  Identification,  Authentication  and  Authorization 

Password  security  remains  the  greatest  threat  to  network  security. 
Passwords  are  transmitted  in  the  clear  over  the  network  whether  that  network  is  the 
campus  backbone  or  the  Internet.  Additionally,  passwords  stored  on  the  system  are 
encrypted  but  the  file  is  world-readable.  Although  CRACI^^  is  run  periodically  to  check 
the  security  of  Unix  passwords,  there  are  no  guarantees  that  a  “good”  password  (i.e.  one 


10  TCP_wrapper  is  a  utility  program  that  allows  system  administrators  to  customize  their 
network  access  security  policy  by  specifying  which  network  hosts  are  granted  or  denied  access  to 
specific  network  services  as  specified  in  the  host,  allow  and  the  host,  deny  files  respectively. 

"  CRACK  is  a  utility  program  that  checks  the  security  of  user  passwords.  The  program 
encrypts  common  dictionaiy  words  and  then  compares  these  words  against  the  system’s 
password  file.  If  a  match  is  found,  the  matched  password  is  flagged  as  insecure.  The  dictionary 
can  be  customized  and  expanded  to  meet  the  needs  of  the  organization.  For  example,  NPS 
includes  ship  names  and  hull  numbers  in  its  CRACK  dictionary.  Information  on  CRACK  is 
available  at  http://www.ja.net/newsfiles/janinfo/cert/Muffett/Crack-4. 1 -readme.txt 
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not  discovered  by  CRACK)  has  not  been  compromised  by  a  password-sniffing  attack. 
Additionally,  although  passwords  are  required  for  remote  login  sessions  originating  from 
any  machine  outside  the  STL  subnet,  the  default  password  for  a  user’s  STL  account  is 
their  main  NFS  Computer  Center  password.  Any  compromise  of  the  main  campus 
password  file  is  likely  to  compromise  the  STL  password  file  as  well.  The  STL  does  not 
require  users  to  use  different  passwords  than  their  main  campus  password  nor  are  users 
required  to  periodically  change  their  passwords.  This  is  an  understandable  local  policy 
since  network  security  monitoring  is  not  coordinated  campus-wide.  Furthermore,  the 
STL  does  not  implement  shadow  passwords  as  recommended  by  CERT  (CERT,  1996c).’^ 

c.  Nonrepudiation 

Nonrepudiation  is  not  an  identified  user  need  and  is  therefore  not  applica¬ 
ble  to  the  STL. 

d.  Integrity  and  Confidentiality 

Integrity  and  confidentiality  of  passwords  during  network  transmission  is 
far  more  important  than  integrity  and  confidentiality  of  data  during  transmission.  This  is 
because  data  can  be  enciypted,  but  encryption  can  be  broken  if  passwords  are  not  secure. 
Preventative  and  corrective  actions  are  needed  because  passwords  are  not  protected 
during  network  transmission.  The  option  of  data  confidentiality  is  a  desirable  feature  for 
some  users  but  is  only  supported  by  ad  hoc  usage  of  routines  such  as  the  Unix  crypt 
command,  a  trivial  encryption  routine  at  best  (Curry,  1990). 

A  shadow  password  system,  does  not  have  encrypted  passwords  in  the  password  field 
of  the  /etc/passwd  file.  The  encrypted  passwords  are  stored  in  a  shadow  file  that  is  not  world- 
readable.  (CERT,  1996c) 
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e.  Network  Connectivity 

(1)  IP-to- ATM  Connections.  Only  preliminary  security  implica¬ 
tions  of  IP  and  ATM  interaction  have  been  considered  by  the  STL  and  NPS  computing 
center  staff.  Admittedly  the  security  implications  are  not  clear  due  to  the  immaturity  of 
ATM  technology.  Nevertheless  if  ATM  implementation  and  use  within  the  STL  is  to 
progress,  security  must  be  planned  in  advance  rather  than  added  as  an  afterthought.  This 
is  an  important  area  for  future  study  before  operational  deployment  of  ATM  at  NPS.  NPS 
ATM  researchers  might  also  consider  membership  in  the  closed  ATM  Forum,  but  true 
security  will  only  emerge  from  open  solutions  compatible  with  IP  and  endorsed  by  the 
IETF.  In  any  case,  the  major  ATM  deficiencies  identified  in  (Courtney,  1996)  must  be 
addressed  prior  to  large-scale  use  of  ATM  is  advisable. 

(2)  Direct-dial  Telephone  Lines.  The  STL  does  not  have  direct 
modem  access.  However,  the  NPS  Computing  Center  and  the  NPS  Computer  Science 
Department  subnets  do  have  modem  access.  Because  the  STL  subnet  is  accessible  from 
these  subnets  via  the  campus  backbone,  its  security  is  dependent  upon  the  security  of 
these  subnets.  The  STL  subnet  may  be  compromised  if  one  of  the  other  subnets  are 
compromised.  The  STL  staff  must  take  the  necessary  steps  to  secure  their  own  subnet 
independent  of  the  security  associated  with  other  subnets  around  the  campus.  This  might 
be  partly  accomplished  by  requiring  passwords  uniquely  different  than  those  used  for 
other  subnets.  This  can  also  be  accomplished  if  a  one-time  password  mechanism  such  as 
S-Key  or  secure  login  mechanism  such  as  Kerberos  is  used  for  dial-in  access  on  the  other 
subnets. 
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(3)  Multicast  Traffic.  Multicasting  is  essential  to  the  work  the 
IIRG  is  doing  with  regards  to  practical  internetworking.  Because  there  are  no  direct 
security  hooks  in  current  multicast  protocols,  current  practice  is  to  use  higher-level 
encryption  for  data  secrecy  and/or  integrity.  The  work  being  done  by  the  IIRG  does  not 
require  such  strict  confidentiality  and  integrity  measures.  What  is  required  is  assurance 
against  denial  of  service.  Certain  MBone  tools  have  been  made  publicly  available  via 
home  pages  using  tools  such  as  mrinfo  and  mtrace.  Granting  public  user-fnendly  access 
to  these  tools  provides  important  benefits  without  opening  security  vulnerabilities  as 
previously  assumed.  (Erdogan,  1996)  provides  a  detailed  examination  of  these  issues,  a 
technical  assessment  of  software  vulnerabilities  and  a  secure  working  implementation 
which  demonstrates  the  value  of  this  approach. 

5.  Implementation  Issues 

a.  Effectiveness  and  Efficiency 

There  are  no  metrics  in  place  by  which  to  measure  the  effectiveness  or 
efficiency  of  computer  security.  System  availability  is  not  monitored  or  tracked.  Labor 
hours  expended  on  security  related  tasks  are  not  documented,  nor  are  the  number  or 
frequency  of  unauthorized  access  attempts.  Until  the  STL  staff  either  implements 
procedures  or  software  tools  to  automatically  monitor  such  metrics,  effectiveness  and 
efficiency  will  go  unmeasured.  This  is  a  valuable  area  for  further  student  research. 

b.  Life-Cycle  Costs 

Security  has  not  been  planned  for  (or  designed  into)  the  unclassified 
systems,  other  than  out-of-the-box  operating  system  security.  There  is  no  documented 


103 


risk  analysis  against  which  to  compare  costs.  Life-cycle  costs  cannot  be  evaluated  xmtil  a 
complete  risk  analysis  is  accomplished.  The  same  metrics  used  to  measure  effectiveness 
and  efficiency  can  be  used  to  track  the  costs  associated  with  the  presence  (or  lack)  of 
security  controls. 

c.  Convenience  and  Acceptance 

While  it  is  true  that  security  controls  must  be  convenient  and  accepted  by 
the  users  if  they  are  to  be  effective,  it  is  also  true  that  the  lack  of  security  controls  must  be 
convenient  and  accepted  by  the  users.  The  lack  of  software  and  data  backups  has 
inconvenienced  STL  users  in  the  past.  Unless  the  present  haphazard  backup  capabilities 
are  changed,  significant  damage  is  likely  to  occur  in  the  future. 

The  STL  computing  staff  must  actively  seek  both  faculty  and  student  input 
concerning  network  security.  All  system  users  (faculty,  staff  and  students  alike)  must 
have  a  voice  in  security  discussions  eind  decisions.  The  computing  staff  needs  to  actively 
seek  input,  because  most  users  will  not  volunteer  such  input  but  will  rather  complain 
amongst  themselves  that  service  is  unsatisfactory. 

D.  SUMMARY 

This  chapter  briefly  describes  the  integrated  IP/ATM  LAN/WAN  network 
topology  at  NPS.  Section  C  documents  in  detail  the  observations  and  conclusions  fi-om  a 
site  security  survey.  The  conclusions  drawn  in  Section  C  are  largely  based  on  the  issues 
discussed  in  Chapter  IV. 
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VII.  EXPERIMENTAL  RESULTS  -  KERBEROS  INSTALLATION 


A.  INTRODUCTION 

This  chapter  explains  the  steps  taken  to  install,  configure  and  test  Kerberos  for  our 
limited  implementation.  Section  B  documents  the  steps  taken  to  obtain  the  software. 
Section  C  briefly  describes  the  steps  taken  to  install  the  Kerberos  software.  Section  D 
describes  configuration  and  testing.  Section  E  briefly  describes  firewall  configuration 
requirements.  Section  F  discusses  the  significance  of  remote  applications  with  respect  to 
network  security  and  the  steps  taken  to  install  and  configure  a  remote  application. 

Section  G  documents  various  configuration  and  techmcal  support  options  available. 
Section  H  describes  the  methods  we  used  to  distribute  Kerberos  passwords  to  both  local 
and  remote  users. 

To  more  easily  examine  the  feasibility  of  Kerberos  we  have  limited  our  test 
implementation  to  a  total  of  five  network  hosts  and  a  portable  laptop  computer.  Because 
the  Kerberos  protocol  is  implemented  strictly  in  software,  no  special  equipment  is 
required.  Locally  we  have  installed  Kerberos  on  three  Unix  workstations  and  a  net¬ 
worked  PC  running  Windows  95.  Remotely  we  have  installed  Kerberos  on  a  portable 
laptop  at  NPS  (also  running  Windows  95)  and  a  single  Unix  workstation  at  Old  Domin¬ 
ion  University  (ODU)  in  Norfolk  Virginia.  We  classify  the  laptop  as  a  remote  machine 
since  laptops  are  typically  used  for  remote  computing  while  traveling.  Figure  10  lists  the 
general  steps  required  to  implement  Kerberos. 
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•  Install  Kerberos  software  on  machines  at  your  site 

•  Set  up  a  Kerberos  Key  Distribution  Center  (KDC) 

•  Configure  Kerberos  application  servers 

•  Configure  Kerberos  application  clients 

•  Add  users  and  their  passwords  to  the  KDC 

•  Inform  users  about  Kerberos 

•  Turn  off  “non-kerberized”  applications  (optional) 

Figure  10.  Steps  required  to  install  Kerberos.  After  (Eichin 
and  McGregor,  1995). 


For  our  limited  implementation  we  established  a  single  realm  with  the  name 
STL.NPS.NAVY.MIL  to  match  the  unique  domain  name  of  our  LAN.  The  realm 
consists  of  a  single  master  Kerberos  Key  Distribution  Center  (KDC),  two  application 
servers  and  six  user  clients  on  the  six  machines  described  above. 

B.  OBTAINING  THE  KERBEROS  SOFTWARE 

Most  Kerberos  source  code  is  freely  available  from  MIT  and  its  authorized 
distribution  agents  via  anonymous  ftp.  While  the  source  code  is  free,  it  incorporates 
64-bit  encryption  and  is  therefore  considered  a  munition  by  the  U.S.  Government.  As 
such  it  is  subject  to  strict  export  restrictions  and  cannot  be  placed  on  well  known  ftp 
servers.  MIT  freeware  information  is  available  at: 

http://athena-dist.  mit.  edu/pub/kerberos 
We  obtained  both  Kerberos  version  4  and  Kerberos  version  5  software  from 
Cygnus  Network  Security  (CNS).  Details  are  described  below. 

1.  Version  4 

Information  and  instructions  for  obtaining  a  copy  of  the  CNS  Kerberos  version  4 
source  code  is  available  at: 
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http:/ ^www.  cygnus.  com/product/cns/sources.  html 
Simply  print  and  complete  the  Cygnus  Network  Security  CNS  (V4)  Package  Request 
Form  and  fax  the  completed  form  to  Cygnus  at  the  number  printed  on  the  form.  Cygnus 
will 

e-mail  ih&ftp  location  in  a  few  business  days.  Due  to  the  export  restrictions,  Cygnus 
must  have  a  signed  form  on  file  before  they  will  release  the  ftp  site  information.  Win¬ 
dows  binaries  (compatible  with  Windows  95,  Windows  3.1X  and  Windows  NT)  are 
freely  available  at  the  anonymous  ftp  site. 

In  addition  to  free  source  code,  Kerberos  binaries  are  also  available  for  a  fee 
(from  a  different server)  for  those  systems  listed  in  Figure  11.  The  fee  is  for  technical 
support  as  described  in  Section  E. 

2.  Version  5 

Due  to  configuration  and  testing  failures  associated  with  the  Kerberos  version  4 
Windows  binaries,  we  purchased  a  special  one-month  support  contract  from  Cygnus.  The 
Kerberos  version  5  binaries  for  Solaris  and  Windows,  and  the  Windows  and  “C”  source 
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Figure  11.  CNS  supported  systems  (CNS,  1996). 
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code  were  included  with  the  contract.  Once  Cygnus  received  a  signed  nondisclosure 
statement  and  payment  for  the  support  contract  they  provided  the  ftp  site  and  the  appro¬ 
priate  information  for  obtaining  support.  The  details  of  the  support  contract  are  discussed 
in  Section  E. 

C.  INSTALLATION 

This  section  describes  installation  procedures  for  the  Kerberos  version  4  software. 
Upgrading  to  Kerberos  Version  5  remains  as  future  work. 

1.  Unix  Machines 

“Root”  access  is  required  to  install  the  Kerberos  software.  Detailed  installation 
steps  are  given  in  (Eichin  and  McGregor,  1995)  and  are  not  repeated  here.  The  docu¬ 
mentation  is  available  on-line  at: 

http://www.  cygnus.  com/library/cns/installjoc.  html 
It  is  advisable  to  print  a  copy  of  the  documentation  for  use  during  the  installation  and 
configuration  process,  rather  than  trying  to  read  the  documentation  on-line  while  install¬ 
ing  the  software.  Figure  12  lists  the  general  steps  required  to  install  Kerberos  on  a  Unix 
machine. 

The  source  code  is  distributed  as  a  zipped  archive  file  and  must  be  unzipped  and 
extracted  using  the  Unix  gunzip  and  tar  utility  programs  respectively.  We  compiled  the 
source  and  then  installed  the  software  on  both  Sun  and  SGI  machines.  Locally,  we  have 
Kerberos  installed  on  a  Sun  SPARCserver  1000  running  Solaris  2.4,  a  Sun  SPARCstation 
20  also  running  Solaris  2.4,  and  an  SGI  Indigo^  workstation  running  IRIX  5.3.  Remotely 
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•  Download  Kerberos  archive  file  from  anonymous  ftp  site 

•  Unzip  and  extract  Kerberos  files 

•  Run  usr/kerberos/configure 

•  Verily  krb.conf  and  krb.  realms  files  are  correctly 
configured 

Figure  12.  General  steps  required  to  install  Kerberos  on  a  Unix 
workstation  (Eichin  and  McGregor,  1995). 

we  have  Kerberos  installed  on  a  single  SGI  Indigo^  Extreme  workstation  at  Old  Domin 
ion  University  (ODU)  in  Norfolk  Virginia,  also  running  IRIX  5.3. 

The  installation  process  is  partially  automated  using  a  configuration  script 
included  with  the  software.  By  default  CNS  Kerberos  version  4  files  are  installed  in  the 
/usr/kerberos  directoiy.  Although  it  is  possible  to  install  Kerberos  in  a  different  directory 
it  is  not  recommended  as  installation  and  configuration  becomes  problematic.  To  install 
the  Kerberos  software  run  the  configuration  script  by  typing: 

% /usr/kerberos/ install/configure 

The  configuration  script  will  prompt  for  the  realm  name  and  automatically 
configure  the  /usr/kerberos/lib/krb.conf  and  /usr/kerberos/lib/krb.realms  configuration 
files.  If  the  realm  name  is  not  the  same  as  the  Internet  domain  name  for  the  site  then 
follow  the  procedures  documented  in  (Eichin  and  McGregor,  1995)  for  manually 
configuring  these  two  files.  Regardless,  it  is  advisable  to  verify  the  entries  in  both  these 
files. 

The  first  two  lines  of  the  krb.  realms  file  will  be  similar  to: 

company . org  MKTG . COMPANY . ORG 
. company . org  MKTG . COMPANY . ORG 
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The  lower  case  portion  of  each  entry  represents  the  domain  name  and  the  uppercase 
portion  is  the  Kerberos  realm  name.  For  our  implementation  these  two  lines  are  modified 
to  read: 

stl.nps.navy.mil  STL.NPS.NAVY.MIL 
.stl.nps.navy.mil  STL.NPS.NAVY.MIL 

Likewise,  the  first  two  lines  in  the  krb.conffAt  will  be  similar  to: 

MKTG.CORP.ORG 

MKTG . CORP . ORG  kerberos . corp . org  admin  server 
For  our  implementation  the  first  two  lines  of  the  krb.conffi\&  are: 

STL.NPS.NAVY.MIL 

STL.NPS.NAVY.MIL  kerberos.stl.nps.navy.mil  admin  server 
The  first  line  is  automatically  added  by  the  configuration  script  to  indicate  the  default 
realm  for  this  machine.  Do  not  change  this  line.  The  second  line  identifies  the  KDC  for 
the  realm.  Manually  edit  these  files  if  the  lines  do  not  accurately  represent  your  configur¬ 
ation. 

2.  Microsoft  Windows  Machines 

Installing  Kerberos  on  Windows  machines  is  much  more  straightforward  than 
installing  Kerberos  on  Unix  platforms.  (Gilmore  and  McGregor,  1995)  provides  detailed 
instructions  for  installing  the  Windows  binaries  and  is  available  on-line  at: 

http://www.  cygnus.  com/library/cns/windowsjoc.  html 
Again,  it  is  advisable  to  print  a  copy  of  the  documentation  for  use  during  the  installation 
process. 

The  Windows  binaries  are  distributed  as  a  zipped  file  that  must  be  unzipped  and 
expanded  with  the  DOS pkunzip  utility  program.  Copy  the  zipped  file  into  the  c:\cns 
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directory  before  it  is  unzipped.  This  is  the  default  installation  directory  and  must  first  be 
created,  unless  installing  an  upgrade  from  an  earlier  version  of  Kerberos  into  the  already- 
existing  directory.  (Gilmore  and  McGregor,  1995)  provides  detailed  instructions  for 
creating  a  CNS  program  group  and  the  necessary  program  items  vdthin  the  CNS  program 
group.  Locally,  we  have  installed  Kerberos  on  a  networked  Pentium  PC  and  on  a 
portable  laptop  for  use  during  travel. 

D.  CONFIGURATION  AND  TESTING  KERBEROS 

Detailed  configuration  procedures  are  presented  in  (Eichin  and  McGregor,  1995) 
and  are  not  repeated  here,  The  documentation  is  available  on-line  at: 

http://www.  cygnus.  com/library/cns/installjoc.  html 
Once  again,  printing  a  copy  for  use  during  the  configuration  process  is  helpful.  Extensive 
manual  pages  are  also  supplied  with  the  software  distribution. 

1.  Key  Distribution  Center  (KDC) 
a.  Configuration 

Configuration  and  administration  of  the  KDC  is  involved  yet  straightfor¬ 
ward.  We  followed  the  configuration  steps  presented  in  (Eichin  and  McGregor,  1995) 
without  difficulty.  Figure  13  lists  the  general  steps  required  to  create,  configure  and 
populate  the  Kerberos  Key  Distribution  Center  (KDC).  These  procedures  require  “root” 
(i.e.  superuser)  access  and  are  partially  automated  using  initialization  and  configuration 
programs.  These  programs  simplify  the  configuration  process  by  prompting  for  any 
required  information.  The  single  KDC  for  our  realm  is  configured  on  the  Sun 
SPARCserver  1000  described  above.  As  specified  in  the  configuration  instructions,  we 
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•  Run  kdbjnit  to  create  the  KDC  database 

•  Run  kdbjedit  to  add  the  first  user 

•  Configure  kadmin  ACLs 

•  Populate  the  KDC  database  using  kadmin  (or  kdbjedit) 

•  Start  kerberos  and  kadmind  daemons 

•  Update  network  /etc/rc  file  (or  equivalent) 

•  Test  for  proper  KDC  configuration  with  kinit 

Figure  13.  General  steps  required  to  create,  configure  and  populate 
the  KDC  database  (Eichin  and  McGregor,  1995). 

added  the  alias  kerberos.stl.nps.navy.mil  for  the  hostname  of  our  KDC  to  the  system 
/etc/hosts  file. 

The  first  step  in  the  configuration  process  is  to  run  the  kdb  jnit  program  to 
create  the  KDC  password  database.  The  first  user  (i.e.  root  as  software  installer)  is 
entered  into  the  database  using  the  kdbjedit  program  to  edit  the  database  directly. 
Additional  users  also  can  be  added  using  kdbjedit  but  it  is  much  easier  to  populate  the 
database  using  the  kadmin  program.  The  kadmin  program  is  enabled  in  the  next  step. 

kdbjedit  differs  fi'om  kadmin  in  that  kdb_edit  can  access  the  database  only  from 
the  machine  on  which  the  KDC  resides  whereas  kadmin  can  access  the  database  from  any 
host  within  the  realm.  For  this  reason,  access  to  the  database  using  kadmin  is  controlled 
by  three  access  control  lists  (ACLs)  that  contain  the  names  of  individuals  who  are 
authorized  to  add,  modify  or  get  information.  The  ACLs  are  stored  as  the  files 
adminjacl.add,  adminjacl.mod and  admin_acl.gei  respectively.  These  files  must  be 
manually  configured  using  a  text  editor. 
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With  at  least  one  user  entered  in  the  database  the  next  step  is  to  start  the 
Kerberos  authentication  server  and  the  database  administration  server  (i.e.  kadmind).  The 
kadmind  daemon  enables  kadmin  program.  Start  these  processes  by  typing: 

%  kerberos  & 

%  kadmind  -n  & 

The  &  causes  these  processes  to  run  in  the  background.  The  -n  option  allows  kadmin  to 
fetch  the  master  database  key  from  the  master  key  cache  file  rather  than  requiring  the 
database  administrator  to  enter  the  master  key  each  time  kadmin  is  run.  (Note:  The 
database  administrator  must  still  enter  their  admin  password  when  executing  one  of  the 
commands  from  within  the  kadmin  program.)  Add  these  two  commands  to  the  network 
/etc/rc  file  (or  equivalent)  to  ensure  Kerberos  is  automatically  restarted  in  the  event  the 
networked  Kerberos  authentication  server  must  be  rebooted. 

The  final  steps  in  configining  the  KDC  are  to  populate  the  database  and  to 
test  the  administration  and  authentication  functions  of  the  KDC.  We  populated  the 
database  with  a  limited  number  of  principals  (i.e.  users)  using  the  kadmin  program.  The 
add  newjcey  command  (ank  for  short)  within  kadmin  is  used  to  add  principals  to  the 
database. 

b.  Testing 

Basic  testing  procedures  are  provided  in  (Eichin  and  McGregor,  1995). 

We  initially  tested  kadmin  by  changing  passwords  for  the  database  administrator  as 
described  in  (Eichin  and  McGregor,  1995).  No  difficulties  were  encountered.  We  also 
tested  kadmin  by  querying  the  database  with  the  get_entry  command  (get  for  short)  to 
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ensure  the  database  had  actually  been  populated.  This  is  an  important  step  as  we 
discovered  when  Professor  Glen  Wheless,  our  research  partner  at  ODU,  was  unable  to 
initialize  to  the  KDC.  Running  get  to  troubleshoot  the  error  indicated  he  had  not  been 
entered  into  our  KDC  database.  Running  ank  and  adding  Professor  Wheless  as  an 
authorized  network  principal  (i.e.  user)  cleared  this  problem. 

We  tested  the  authentication  server  portion  of  the  KDC  by  running  the 
kinit  command  from  both  local  and  remote  hosts.  The  proper  syntax  is: 

%  kinit  username 

Initial  tests  from  local  machines  returned  a  “Principal  unknown”  error  indicating  that  the 
principal  (i.e.  username)  had  not  been  added  to  the  database  or  that  kinit  was  searching 
the  wrong  KDC.  However  we  were  able  to  successfully  initialize  by  using  the  -r  option 
with  kinit  to  specify  the  realm.  The  proper  syntax  for  this  is; 

% kinit  -r  username@realm 

Upon  further  investigation,  we  discovered  that  this  is  a  common  error  and  is  documented 
in  (Eichin  and  McGregor,  1995).  To  avoid  having  to  use  the  -r  option,  add 
/usr/kerberos/bin  prior  to  /usr/bin  in  your  path  variable.  We  discovered  quite  by  accident 
that  this  is  required  because  the  Solaris  operating  system  is  shipped  with  a  default, 
different  version  of  Mnit  installed  in  /usr/bin.  Without  redefining  the  path  variable  we 
were  using  the  wrong  version  of  kinit.  Testing  kinit  from  remote  client  machines  is 
discussed  below. 
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2.  Application  Servers 


a.  Configuration 

For  our  implementation  the  Sun  SPARCserver  1000  and  the  Sun 
SPARCstation  20  are  configured  as  application  servers.  Again  we  followed  the  configu¬ 
ration  steps  presented  in  (Eichin  and  McGregor,  1995)  without  difficulty.  We  configured 
the  application  servers  to  support  the  “kerberized”  versions  of  the  Berkeley  r-command 
applications  (i.e.  rlogin,  rep,  and  rsh),  but  we  did  not  disable  the  standard  versions  of  the 
applications.  Users  select  one  version  or  another  by  specifying  the  complete  path  for  the 
application  on  the  command  line  when  running  the  application  (e.g. 
/urs/kerberos/bin/rlogin),  or  by  placing  /usr/kerberos/bin  prior  to  /mr/bin  in  the  path 
variable  as  discussed  earlier.  No  other  “kerberized”  applications  (e.g.  telnet  or  ftp)  are 
enabled.  Figure  14  lists  the  general  steps  required  to  configure  a  Kerberos  application 
server. 

The  first  step  required  to  configure  a  machine  as  a  “kerberized”  applica¬ 
tion  server  is  to  add  a  service  instance  and  password  for  that  server  to  the  KDC.  (Recall 
every  “kerberized”  service/server  combination  requires  a  password.)  To  configure  the 


•  Add  service  instance  to  the  KDC  using  kadmin. 

•  Configure  the  service  on  the  application  server  with  ksrvutil  add. 

•  Change  the  service  password  with  ksrvutil  change. 

•  Update  the  /etc/inetd.conf  f\\&. 

•  Test  the  service. 

•  Turn  off  “non-kerberized”  versions  of  the  service. 

Figure  14.  General  steps  required  to  configure  Kerberos  application  servers 
(Eichin  and  McGregor,  1995). 
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“kerberized”  Berkeley  r-command  suite  on  the  server  servername  first  run  kadmin  then  at 

the  admin  prompt  enter  the  following: 

admin:  ank  rcmd. servername 

You  are  prompted  for  a  password.  At  this  point  the  peissword  can  be  simple  as  it  soon 
will  be  changed  to  something  only  the  server  and  the  KDC  know. 

To  configure  the  service  on  the  server  itself,  first  log  in  to  the  server  as 
“root”  then  type: 

%ksrvutil  add 

Again  you  are  prompted  for  the  service’s  password.  Enter  the  same  password  used  when 
adding  the  service  to  the  KDC.  Next  run  the  ksrvutil  change  program  to  automatically 
change  the  simple  password  to  something  only  the  KDC  and  the  application  server 
knows.  The  correct  syntax  is: 

% ksrvutil  change 

Finally,  update  the  /etc/inetdconf  f\\e  as  specified  in  (Eichin  and  McGregor,  1995)  and 
test  the  application  server. 

b.  Testing 

Full  operational  testing  of  the  application  servers  cannot  be  done  until 
clients  are  configured.  However,  simply  installing  Kerberos  on  the  KDC  machine  and  the 
application  server  machine  makes  them  client  machines  as  well.  Testing  the  application 
servers  with  client  machines  is  discussed  below.  Initial  communications  between  the 
KDC  and  the  application  server  can  be  tested  prior  to  running  ksrvutil  change  by  typing: 
%  kinit  rcmd . servername 
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Refer  to  (Eichin  and  McGregor,  1995)  for  troubleshooting  hints  ifkinit  fails.  Destroy  all 
tickets  when  finished  testing.  The  proper  syntax  to  destroy  all  tickets  is  simply: 

%  kdestroy 

3.  Clients 

a.  Unix  Machines 

(1)  Configuration.  As  mentioned  above,  Unix  machines  can  be 
configured  as  Kerberos  clients  simply  by  installing  the  Kerberos  software  as  described  in 
Section  C.  Therefore  the  two  application  servers  are  also  configured  as  user  clients. 
Additionally,  the  SGI  Indigo^  workstation  at  NFS  and  the  SGI  Indigo^  Extreme  worksta¬ 
tion  at  ODU  are  configured  as  clients.  Figure  15  lists  some  basic  services  that  can  be 
included  in  the  /etc/services  file  on  each  client  machine.  Only  kerberos  and  kpasswd  are 
necessary  to  allow  principals  to  initialize  to  the  KDC.  klogin  or  eklogin  is  required  to 
enable  the  “kerberized”  rlogin  application  (with  or  without  encryption  respectively). 
Other  services  or  “kerberized”  applications  (such  as  kpop,  a  “kerberized  e-mail  server 
daemon)  can  be  added  as  required. 


Service 

Port/ 

Protocol 

Comments 

kerberos 

750/udp 

#  Kerberos  (server)  udp 

kerberos 

750/tcp 

#  Kerberos  (server)  tcp 

kpasswd 

761/tcp 

#  Kerberos  "passwd" 

klogin 

543/tcp 

#  Kerberos  authenticated 

rlogin 

eklogin 

2105/tcp 

#  Kerberos  encrypted  rlogin 

kshell 

544/tcp 

it  and  remote  shell 

Figure  15.  Kerberos  version  4  services  and  port  numbers  (Cygnus, 


1996). 
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(2)  Testing.  Operational  testing  consists  of  attempting  to  access 
the  services  provided  by  the  application  servers.  Prior  to  testing,  ensure  /usr/kerberos/bin 
is  placed  in  the  path  variable  ahead  of /usr/bin.  In  our  case  only  the  “kerberized” 
r-commands  are  configured.  Our  tests  consisted  of  initializing  to  the  KDC  with  kinit  and 
testing  the  rlogin  service  from  all  clients  to  both  application  servers.  We  ran  both 
unencrypted  and  encrypted  rlogin  sessions.  The  proper  syntax  for  this  sequence  of  tests 
is: 

%  kinit  username 

%  rlogin  servername  #  unencrypted  session 

%  rlogin  -x  servername  #  encrypted  session 

Tests  between  local  clients  and  the  servers  proved  successful.  However, 
testing  the  remote  client  at  ODU  has  been  unsuccessful.  All  attempts  to  initialize  to  the 
KDC  up  to  this  point  have  resulted  in  a  sendjojcdc:  retry  count  exceeded  error. 
According  (Eichin  and  McGregor,  1995)  this  indicates  that  kinit  cannot  reach  the  KDC 
and  the  most  likely  cause  is  a  misconfigured  krb.conf.  The  krb.conf  and  krb. realms  files 
were  correct,  but  to  verify  these  results  we  deleted  the  krb.conffilt  and  re-ran  the 
configure  installation  and  configuration  script.  The  same  results  were  obtained  on 
subsequent  tests. 

We  are  fairly  certain  that  the  problem  is  not  with  the  client  software  itself 
or  a  problem  with  the  client  configuration  because  the  initialization  attempts  are  being 
recorded  in  the  kerberos.log  log  file  indicating  the  client  is  reaching  the  KDC  but  the 
KDC  is  not  responding  to  the  request.  Requesting  technical  support  from  Cygnus  to 
solve  this  problem  proved  to  be  of  little  value  since  our  support  contract  covers  only 
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version  5.  Time  and  schedule  constraints  did  not  permit  resolution  of  the  problem 
without  technical  support,  and  as  we  move  to  implement  Kerberos  version  5  this  problem 
with  version  4  remains  unresolved. 

b.  Microsoft  Windows  Clients 

(1)  Configuration.  (Gilmore  and  McGregor,  1995)  describe  the 
steps  required  to  configure  Kerberos  for  Windows.  The  krb.rea  and  krb.con  (DOS 
versions  of  the  krb. realms  and  krb.conf  fAcs)  must  be  configured  during  installation 
exactly  as  on  the  Unix  machines.  We  installed  and  configured  our  Windows  clients 
according  to  (Gilmore  and  McGregor,  1995).  The  networked  PC  and  the  portable  laptop 
are  configured  as  clients. 

(2)  Testing.  Testing  the  Windows  95  clients  also  proved  to  be 
problematic.  All  attempts  to  initialize  to  the  KDC  using  a  Windows  95  client  resulted  in 
the  same  sendjojcdc:  retry  count  exceeded  error.  Both  the  krb.con  and  krb.rea  files 
(i.e.  the  DOS  equivalents  to  the  krb.conf  dind  krb.realms  files)  were  configured  according 
to  (Gilmore  and  McGregor,  1995).  Posting  our  problem  to  the  comp.protocols.kerberos 
USENET  newsgroup  did  not  yield  any  useful  responses  and  technical  assistance  was  not 
available  since  CNS  advised  that  Kerberos  version  4  was  not  supported.  As  with  our 
remote  Unix  client,  this  version  4  problem  remains  unresolved.  At  the  time  of  this 
writing  we  are  replacing  our  Kerberos  version  4  Windows  implementation  and  progress¬ 
ing  with  version  5  implementation. 


119 


E. 


FIREWALL  CONFIGURATION 


Figure  15  lists  various  Kerberos  services  together  with  the  corresponding  trans¬ 
port  layer  protocol  (TCP  or  UDP)  and  network  port  numbers  that  each  uses.  If  your 
network  security  architecture  includes  a  firewall,  it  must  be  configured  to  allow  these 
service/port  combinations  to  pass.  The  IP  address  for  each  “kerberized”  host  may  also  be 
required  depending  on  your  firewall.  The  firewall  configuration  for  our  implementation 
is  listed  in  Figure  16.  Local  clients  need  not  be  included  in  the  firewall  configuration 


Local  Servers; 

131.120.64.5 

spot.stl.nps. navy  .mil  131.120.64.4 

azure.stl.nps.navy.mil 

Remote  Clients:  garcia.ccpo.odu.edu  128.82.38.141 

Port/ 

Service 

Protocol 

Comments 

kerberos 

750/udp 

#  Kerberos  (server)  udp 

kerberos 

750/tcp 

#  Kerberos  (server)  tcp 

kpasswd 

761/tcp 

#  Kerberos  "passwd" 

klogin 

543/tcp 

#  Kerberos  authenticated  rlogin 

eklogin 

2105/tcp 

#  Kerberos  encrypted  rlogin 

kpop 

1109/tcp 

#  Pop  with  Kerberos 

kshell 

544/tcp 

#  and  remote  shell 

Figure  16.  Firewall  configuration  for  the  NPS  Kerberos 
implementation. 


table.  The  benefit  of  Kerberos  remains  that  a  particular  host  does  not  need  to  be  trusted 
as  the  protocol  authenticates  individual  users  rather  than  rely  on  the  trustworthiness  of 
any  particular  host. 
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F.  REMOTE  APPLICATIONS 

Successful  implementation  of  Kerberos  is  measured  by  the  ability  of  remote  users 
to  securely  access  our  system  and  conduct  useful  work.  Our  measure  of  success  was 
secure  access  to  our  system  by  Professor  Wheless  and  the  successful  execution  on  our 
system  of  the  Vis5D  application  software  used  by  Professor  Wheless  at  ODU. 

1.  VisSD  Download  and  Installation 

The  latest  version  of  the  Vis5D  application  software  (Hibbard,  1996)  is  available 
at: 

http://www.  ssec.  wise.  edu/-~billh/vis5d.  html 
Both  source  and  executable  code  is  available.  Downloading  unknown  or  imfamiliar 
executable  code  from  the  Internet  is  not  recommended  as  a  general  rule,  but  we  chose  to 
download  the  executables  for  two  reasons.  First,  inspecting  source  code  for  security 
vulnerabilities  or  mischievous  code  is  not  effective.  Second,  this  particular  software  is 
written  by  a  reliable  source  and  was  recommended  by  a  trusted  colleague. 

2.  Execution 

We  tested  the  VisSD  software  locally  to  ensure  we  correctly  installed  and  config¬ 
ured  the  software.  However,  Professor  Wheless  could  not  securely  access  our  system  to 
remotely  execute  the  software.  Therefore  we  did  not  accomplish  our  remote  application 
goals. 
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G.  CONFIGURATION  SUPPORT 


While  Cygnus  distributes  the  Kerberos  source  code  at  no  charge,  technical  support 
requires  payment.  Cygnus  offers  a  variety  of  standard  support  packages  for  their 
Kerberos  distribution.  These  support  packages  for  a  single  realm  are  listed  in  Figure  17. 

Due  to  configuration  difficulties  with  the  Kerberos  version  4  Windows  binaries 
we  contracted  for  a  special  one-month  support  agreement  with  Cygnus.  Because  our 
Kerberos  implementation  is  only  experimental  at  this  stage,  Cygnus  agreed  to  customize  a 
support  contract  to  fit  our  particular  needs.  We  purchased  a  one-month  contract  for 
$1,000.  Our  sole  purpose  for  the  support  agreement  was  to  obtain  assistance  with  the 
configuration  of  the  Kerberos  version  4  binaries  for  Windows.  We  did  not  discover  the 
similar  problem  with  the  remote  Unix  client  at  ODU  imtil  after  the  support  contract  was 
obtained. 

Cygnus  relies  exclusively  on  electronic  mail  to  report  software  problems/bugs  and 
to  obtain  assistance.  An  automated  report  generation  program  (send-pr)  is  included  in  the 
supported  distribution  of  the  Kerberos  software  which  is  not  included  in  the  freeware 
distribution.  This  automatic  reporting  procedure  proved  to  be  one  more  obstacle  to 
hurdle.  Due  to  the  short  duration  of  our  contract  we  did  not  take  the  time  to  install  send- 
pr  but  instead  used  standard  electronic  mail  to  obtain  assistance.  While  Cygnus  attempts 
to  answer  all  reports  within  24  hours,  it  was  two  days  before  we  received  a  reply  to  our 
report. 

As  mentioned  above,  our  sole  purpose  for  obtaining  support  was  to  solve  the 
perceived  Kerberos  version  4  eonfiguration  problem  with  the  Windows  95  elients. 
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Available  Cygnus  Kerberos  Support  Contracts 


Single  Realm  Support: 

1000 

Principals 

5000 

Principals 

Enterprise 

University 

$  9,000 

$  15,000 

custom 

Government 

$  24,000 

$  49,995 

custom 

Commercial 

$  35,000 

$  60,000 

custom 

Client  Support  (cost  per  client): 

Same  as 

PC  or  Mac 

Server 

Client 

Unix 

University 

included 

$  1,500 

$  1,500 

Government 

included 

$  2,500 

$  2,000 

Commercial 

included 

$  5,000 

$  2,500 

Feature  Support  (in  addition  to  base  prices  above): 


CNS  Developer’s  Kit  (CDK) 

(  Support  for  Kerberos  libraries) 


Existing  CDK  customer 

$  5,000 

Non-CDK  customer 

$  15,000 

Hand'held  Authenticator 

$  5,000 

AFS  Support 

$  25,000 

New  dot  on  Matrix 

custom 

Multiple  realms  or  slave  KDCs 

at  multiple  sites 

custom 

Figure  17.  Standard  support  agreements  available  from  Cygnus  for  CNS  Kerberos 
distribution  (Powers,  1996). 
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However  Cygnus  technical  support  informed  us  in  their  reply  to  our  problem  report  that 
our  contract  was  for  version  5  only.  It  was  our  understanding  that  the  support  contract 
was  for  Kerberos  version  4.  Cygnus  was  very  helpful  and  flexible  in  customizing  a 
contract  for  us  so  we  can  only  attribute  this  misunderstanding  to  mis-communication 
between  the  parties.  Therefore  while  we  pursue  a  version  5  installation  our  version  4 
implementation  difficulties  remain  unresolved.  We  are  removing  the  version  4  distribu¬ 
tion  to  eliminate  the  possibility  of  mismatched  software  versions. 

H.  KERBEROS  PASSWORD  DISTRIBUTION 

1.  Local  Users 

Passwords  are  distributed  to  local  users  face-to-face.  Users  must  see  a  system 
administrator  to  establish  both  a  local  account  and  to  be  entered  in  the  Kerberos  database. 
The  Kerberos  database  entry  does  not  have  to  be  the  same  as  the  local  accoxmt  user  ID 
and  password.  However,  making  the  two  the  same  and  including  the  Kerberos  initialize 
procedure  in  the  login  script  is  recommended.  This  makes  the  Kerberos  initialization 
procedure  transparent  to  the  user. 

2.  Remote  Users 

Passwords  for  remote  users  can  be  distributed  over  the  telephone.  Our  procedure 
is  to  telephone  the  remote  user  and  have  a  trusted  individual  who  knows  the  remote  user 
authenticate  them  either  by  their  voice  or  by  some  unique  information  only  the  two  share. 
While  the  PSN  is  vulnerable  to  tapping,  we  assume  the  risk  of  compromise  to  be  negligi¬ 
ble. 
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SUMMARY 


This  chapter  explains  the  steps  required  to  obtain,  install  and  configure  the 
Kerberos  version  4  software  for  both  Unix  machines  and  Microsoft  Windows  machines. 
Installation  and  configuration  test  results  are  also  included.  Firewall  configuration 
requirements  are  discussed  in  Section  E.  Section  F  explains  the  steps  taken  to  install  and 
test  an  application  used  by  our  remote  research  partner,  Professor  Glen  Wheless,  at  Old 
Dominion  University.  Execution  of  the  application  over  a  secure  channel  by  Professor 
Wheless  is  the  primaiy  indication  of  a  successful  Kerberos  implementation.  Section  G 
discusses  support  contracts  offered  by  Cygnus  for  their  Kerberos  version  4  distribution. 
Section  G  also  explains  the  specifics  and  motivation  for  a  customized  support  contract 
Cygnus  provided  for  NPS.  Section  H  details  the  steps  taken  to  distribute  Kerberos 
passwords  to  both  local  £ind  remote  users. 
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VIII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  INTRODUCTION 

This  chapter  draws  conclusions  about  Kerberos  and  makes  recommendations 
concerning  the  security  of  the  integrated  IP/ATM  LANAVAN  at  NPS.  Section  B  presents 
our  conclusions  and  Section  C  presents  recommendations  for  additional  and  future  work. 

B.  RESEARCH  CONCLUSIONS 

1.  STL  Site  Security 

Despite  specific  items  discussed  in  Chapter  VI,  site  security  for  the  STL  is 
relatively  good.  The  STL  network  administrators  deserve  to  be  commended  for  their 
superlative  technical  knowledge,  dedication  to  meeting  user  requirements,  and  ability  to 
succeed  despite  improper  manning.  The  STL  computing  staff  have  installed  the  latest 
security  patches  for  system  software,  TCP_wrapper  is  used  for  all  intra-campus  network 
communications,  the  staff  plans  to  install  an  automated  backup  system,  and  an  air 
conditioning  system  is  supposed  to  be  installed  before  the  end  of  the  year. 

Based  on  our  observation  and  site  security  assessment,  most  security  risks  for  the 
STL  environment  are  relatively  low.  However  there  are  still  some  vulnerabilities  and 
deficiencies.  Recommendations  are  provided  below. 

2.  ATM  Security 

Chapter  II  demonstrated  that  ATM  can  be  as  susceptible  to  attack  as  any  other 
network  technology;  security  is  still  a  concern  when  using  ATM  and  fiber  optic  cables. 
ATM  technology  is  immature  and  new  vulnerabilities  will  likely  emerge  as  experience  is 
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gained  through  research  such  as  that  conducted  by  the  IIRG  at  NPS  and  research  testbeds 
such  as  the  Monterey  BayNet  regional  ATM  network.  Much  research  and  testing  is  still 
required  before  security  implications  associated  with  combining  ATM  with  other 
networking  protocols  such  as  IP  are  well  known.  Open  communications  among  the 
commercial,  scientific  and  educational  communities  are  essential  for  discovering  and 
correcting  possible  vulnerabilities.  Open  communications  are  essential  if  ATM  is  to  live 
up  to  its  much  publicized  promises.  To  date,  reports  by  the  ATM  Forum  have  been 
largely  inaccessible  and  progress  by  the  IETF  working  group  has  been  incomplete. 

3.  Kerberos  Implementation 

We  assume  that  host  machines  on  local-area  networks  behind  a  firewall  are 
relatively  secure  even  though  some  firewalls  are  vulnerable  to  address-spoofing  attacks. 
We  also  assume  that  the  network  separating  the  firewalls  is  insecure.  The  purpose  of  our 
Kerberos  implementation  then  is  to  connect  two  secure  hosts  across  an  insecure  network 
cloud,  in  this  case  the  Internet.  Kerberos  is  well  suited  for  this  task  and  can  be  an 
effective  addition  to  an  organization’s  network  security  architecture.  Kerberos  is 
effective  against  both  password-sniffing  attacks  and  address-spoofing  attacks.  Even  if  a 
an  intruder  is  able  to  penetrate  a  firewall  using  an  address-spoofing  attack,  a  “kerberized” 
host  behind  the  firewall  is  secure.  Figure  1 8  illustrates  the  value  Kerberos  can  add  value 
to  the  organization’s  security  architecture.  However,  Kerberos  is  not  widely  used  and 
therefore  can  be  difficult  to  implement.  It  is  not  yet  a  mature  “plug-and-play”  software, 
but  requires  considerable  effort  to  install  and  configure.  Implementing  Kerberos  on  a 
large  scale  (such  as  a  campus)  requires  considerable  planning. 
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Figure  18.  Value  of  Kerberos  within  an  organization’s  security  architecture. 


We  limited  the  scope  of  this  thesis  as  much  as  possible  from  the  beginning 
because  (in  our  experience)  implementation  projects  are  seldom  as  straightforward  as 
anticipated.  This  proved  to  be  true  in  this  case  as  well.  We  have  been  partially  successful 
with  our  implementation  of  Kerberos,  but  installation  and  configuration  was  not  as  simple 
as  first  anticipated.  Configuring  and  operating  Kerberos  between  Unix  platforms  is 
relatively  straightforward  and  successful,  but  configuration  of  Windows  clients  was 
problematic  and  still  has  not  worked.  Our  ability  to  easily  operate  “kerberized”  applica¬ 
tions  across  the  Internet  between  Windows  and  Unix  is  required  if  Kerberos  is  to  be  of 
use  to  NFS. 
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C.  RECOMMENDATIONS  FOR  FUTURE  WORK 

1.  Related  Work:  NFS  Theses 

The  IIRG  continues  to  produce  numerous  significant  theses  on  internetworking. 
Thesis  security  considerations  are  usually  addressed  informally.  Future  IIRG  internet¬ 
working  theses  need  to  include  a  separate  chapter  comprehensively  addressing  security 
issues.  Such  an  approach  has  been  required  for  all  IETF  Requests  for  Comments  (RFC) 
documents  (Postel,  1 993). 

Restricting  access  to  past  or  future  NFS  theses  on  unclassified  network  computing 
security  makes  little  sense.  Restricting  access  to  a  thesis  simply  because  it  documents 
networked  computer  system  security  vulnerabilities  removes  the  motivation  to  improve 
security  but  does  not  remove  the  possibility  that  those  vulnerabilities  may  be  exploited. 
Access  to  such  theses  needs  to  be  unrestricted  if  effective  action  is  to  be  taken  to  improve 
networked  computer  system  security. 

2.  Site  Security 

a.  Administration  Issues 

The  fundamental  security  concern  for  an  unclassified  system  is  not 
necessarily  data  integrity  or  confidentiality  but  rather  maintaining  system  availability. 

The  STL  computing  staff  must  determine  and  document  the  system  availability  require¬ 
ments.  They  need  to  conduct  a  formal  risk  analysis  and  prepare  detailed  contingency 
plans  for  the  unclassified  systems  to  ensure  that  system  availability  requirements  are  met. 
Additionally  an  automatic  network  monitoring  system  such  as  is  documented  in  (Ed¬ 
wards,  1996)  and  (Erdogan,  1996)  needs  to  be  implemented. 
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The  STL  computing  staff  needs  to  re-examine  the  current  security  and 
acceptable  use  policies  (AUPs)  and  revise  them  where  necessaiy  to  reflect  the  current 
environment  and  culture  of  NPS.  A  signed  consent  form  acknowledging  the  security 
policies  and  AUPs  ought  to  be  required  from  all  personnel  using  computing  resources  at 
NPS. 

It  is  recommended  the  STL  computing  staff  implement  a  user  indoctrina¬ 
tion  program  for  their  unclassified  systems  similar  to  the  program  used  for  their  classified 
systems.  Additionally,  it  is  recommended  a  first  quarter  basic  computer  security  course 
be  required  for  every  student  at  NPS. 

The  NPS  administration  needs  to  expedite  funded  STL  requests  for 
additional  staff.  Six  months  between  staff  departure  and  opening  a  relief  billet  is 
unacceptably  long. 

Lastly,  documentation  concerning  the  December  1995  computer  security 
breach  at  NPS  is  scarce  at  best.  The  NPS  computer  center  staff  needs  to  document  and 
widely  distribute  information  concerning  the  break-in.  While  this  is  not  to  say  specific 
information  about  the  network  security  architecture  at  NPS  ought  to  be  released,  but  open 
communication  between  computer  system  administrators,  computer  users  and  the  NPS 
administration  is  essential  to  avoid  similar  incidents  in  the  future. 

b.  Environmental  Issues 

Physical  security  within  the  STL  can  be  improved.  The  main  network  file 
server  and  the  Kerberos  authentication/database  server  are  freely  accessible  to  anyone. 
These  two  servers  need  to  be  moved  to  a  more  physically  secure  environment.  Network 
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connections  also  remain  vulnerable.  The  STL  computing  staff  needs  to  implement  ways 
to  reduce  these  vulnerabilities. 

c.  Software  and  Data  Issues 

The  STL  computing  staff  needs  to  utilize  a  configuration  management 
program  for  application  software.  The  most  logical  control  mechanism  is  some  form  of 
centralized  administrative  record.  At  a  minimum,  the  record  must  include  the  purpose  of 
the  software,  the  student  or  faculty  member  for  whom  the  application  is  installed,  the 
current  version,  the  current  location  and  the  expected  review  or  completion  date. 
Consulting  the  application  log  when  students  depart  will  allow  the  STL  computing  staff 
to  remove  any  application  programs  that  are  no  longer  required. 

The  STL  network  manager  needs  to  accelerate  implementation  of  an 
automated  backup  mechanism.  With  an  automated  system,  complete  system  backups  can 
be  performed  monthly  with  incremental  backups  performed  weekly.  Backups  must 
include  user  data  files  as  well  as  system  files. 

d.  Telecommunications  and  System  Access  Issues 

Password  security  over  the  Internet  remains  a  significant  vulnerability. 
This  vulnerability  affects  all  systems  on  campus,  not  just  those  in  the  STL.  Despite  the 
installation  and  configuration  challenges  we  experienced,  Kerberos  is  a  promising  option 
that  should  be  explored  further.  NPS  also  needs  to  consider  implementing  a  one-time 
password  (OTP)  protocol  (such  as  S-Key)  for  dial-up  connections. 
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3. 


ATM 


If  ATM  research  and  implementation  at  NFS  continues,  NFS  needs  to  seek 
membership  in  the  ATM  Forum.  With  an  emphasis  on  practical  networking  and  internet¬ 
working,  the  IIRG  and  other  researchers  at  NFS  can  be  a  powerful  voice  in  the  develop¬ 
ment  of  interoperable  ATM  standards. 

4.  Kerberos 

Although  the  campus  network  security  architecture  now  includes  a  firewall  and 
the  use  of  TCPjvrapper  for  all  intra-campus  network  communications,  the  network  is 
still  vulnerable  to  password-sniffing  by  imdetected  sniffer  programs  and  address-spoof¬ 
ing.  Kerberos  version  4  effectively  reduces  this  vulnerability  but  it  is  not  without  its  own 
weaknesses.  Many  of  these  weaknesses  have  been  eliminated  in  version  5.  Therefore 
upgrading  the  limited  implementation  of  Kerberos  in  the  STL  to  version  5  is  a  priority. 
Continued  work  is  also  required  with  configuring  Windows  clients. 

A  final  recommendation  is  for  NFS  to  investigate  the  feasibility  of  a  campus-wide 
implementation  of  Kerberos.  It  is  safe  to  assume  there  will  be  much  resistance  to  the  use 
of  Kerberos.  Implementing  Kerberos  will  require  change,  and  change  is  never  an  easy  nut 
to  crack.  Much  of  this  resistance  is  likely  to  come  fi-om  system  administrators,  many  of 
whom  view  Kerberos  as  burdensome  and  obtrusive.  However,  configuring  and  managing 
a  Kerberos  site  does  not  have  to  be  any  more  burdensome  than  managing  a  non-Kerberos 
site.  It  will  only  become  burdensome  if  system  administrators  are  expected  to  manage 
both  independently.  Kerberos  can  be  as  “unobtrusive”  as  the  standard  login  sequence; 
users  will  never  know  the  difference. 
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It  is  clear  that  careful  and  detailed  planning  will  be  essential  for  a  successful 
campus-wide  implementation  of  Kerberos.  Implementing  a  commercial  version  of 
Kerberos  including  technical  support  will  be  much  less  problematic  than  implementing  a 
freeware  version  of  the  software.  NFS  needs  to  investigate  such  an  option. 

D.  SUMMARY 

It  is  clear  that  networked  computer  security  is  a  multifaceted  problem,  that 
encompasses  both  social  and  technological  issues.  This  duality  was  illustrated  throughout 
this  thesis.  There  remains  much  work  and  research  to  be  done  in  the  areas  of  networking 
and  networked  computer  security.  This  chapter  presents  conclusions  concerning  the 
security  of  the  integrated  IP/ATM  LAN/WAN  at  NFS,  ATM  security  and  the  Kerberos 
authentication  and  authorization  protocol.  Recommendations  for  continued  and  future 
work  are  also  presented.  The  most  significant  result  presented  here  is  that  secure 
collaborative  networked  research  by  scientists  and  students  distributed  around  the  Internet 
is  achievable.  A  small  amount  of  additional  work  and  testing  is  required  to  make  that 
promise  a  reality. 
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APPENDIX  A.  ON-LINE  THESIS  DISTRIBUTION 


Hypertext  markup  language  (HTML)  and  PostScript  versions  of  this  thesis  are  available 
at: 

http://www.  stl  nps.  navy.  mil/~iirg/dennis/thesis.  html 
Comments  or  questions  can  be  addressed  to  Don  Brutzman  at  NPS.  His  e-mail  address 
is: 


brutzman@cs.nps.navy.mil 
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APPENDIX  B.  ON-LINE  KERBEROS  DISTRIBUTION 


A.  Kerberos  Documentation  and  Software  Distribution 

Kerberos  software  is  available  as  freeware  but  its  distribution  within  the  United 
States  is  controlled  because  of  U.S.  export  restrictions  on  cryptographic  software. 
Information  about  obtaining  the  Kerberos  version  4  or  version  5  software  can  be  found  at 
the  following  URLs. 

Cygnus  Network  Security 

Obtaining  the  Software 

http://www.  cygnus.  com/product/cns/sources.  html 
Documentation 

http://www.  cygnus.  com/l ibrary/cns/installjoc.  html  for  Unix 

http://www.  cygnus.  com/library/cns/windowsjoc.  html  for  Windows 

Note:  Only  version  4  documentation  is  available.  Version 
5  documentation  is  not  yet  available  on-line. 


MIT 


Obtaining  the  Software  and  Documentation 
http://athena-dist.  mit.  edu/pub/kerberos 

B.  Technical  Support 

Technical  support  is  not  provided  with  the  distribution.  Cygnus  does  offer 
technical  support  for  a  fee  for  their  distribution  of  both  Kerberos  version  4  and  version  5. 

C.  Kerberos  Related  Papers 

An  excellent  clearing  house  for  Kerberos  related  papers  is  at: 

http://nii.  isi.  edu/gost-group/products/kerberos/documentation.  html 
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